1. Compiling Euphoria 3+ for non-x86 targets
With the change of Euphoria to an open source model, I'm wondering if any
thought is being given to how non-x86 ports are going to be handled within
the source.
Some of you might remember that I ported a (mostly) working version of Eu
2.4 to my Sharp Zaurus clamshell pda, ARM/Xscale/Linux, back when the source
was fully C. I managed to get Eu 2.5 (partly broken) compiled for the Z
using a halfway house method of translate on Linux PC, compile on Zaurus.
This time, I've completed a successful but completely broken compile of
3.0.2, using the 2.4 interpreter on my Z to run the new PD translator (2.4
is missing the '$' shorthand and it was necessary to replace a few instances
of that with 'length()' ) The resulting interpreter segfaults immediately
following the file request message. I'm not too concerned about that as
there is a lot to do in the source. A lot of what needs to be done is, I'm
guessing, going to be just like what I've already done in 2.4. Transferring
all of that to the 3.0.2 source is going to be very tedious.
Is there any way we could keep track of where changes have been made in the
source? Perhaps a formal method for commenting them, like "//change: V3.0.2
[code....] //end change"? This could be quickly searched for using a text
editor, providing it was consistent.
Btw, is anyone else porting to a non-x86 platform? I'd be particularly
interested to hear from any ARM gurus who would be willing to help me with
the ARM asm code. My poor effort (necessary to implement shared lib calling)
worked in 2.4 but refused to do so in 2.5.
Mark
2. Re: Compiling Euphoria 3+ for non-x86 targets
Mark Brown wrote:
>
> Is there any way we could keep track of where changes have been made in the
> source? Perhaps a formal method for commenting them, like "//change: V3.0.2
> [code....] //end change"? This could be quickly searched for using a text
> editor, providing it was consistent.
>
Now that we've got everything in subversion, we have a detailed diff record
of what has changed. You can get these through svn commands.
Matt
3. Re: Compiling Euphoria 3+ for non-x86 targets
Matt Lewis wrote:
> Now that we've got everything in subversion, we have a detailed diff record
> of what has changed. You can get these through svn commands.
If you want to set up tags and branches
subdirectories, feel free. I'm not sure if
the trunk should be called "trunk", with "euphoria" inside,
or simply "euphoria".
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Compiling Euphoria 3+ for non-x86 targets
Matt wrote:
> Now that we've got everything in subversion, we have a detailed diff
record
> of what has changed. You can get these through svn commands.
Thanks for the info Matt. I probably should have checked the list archive
for that before posting... haven't read the list much of late.
Regarding the seg fault I'm getting, I've tracked it down to symtab.e in
procedure InitSymTab(). Specifically the crash occurs at the line "while
SymTab[s][S_SAMEHASH] != 0 do"
That line doesn't look weird in any way to me, except that I think it is the
first instance of a "while" being used in the eu code. I'm a bit scared of
that as I'm guessing that means that my compiled eu while loops are broken.
Rob, could you perhaps point me in a direction to look for this. Is this
sort of thing all still in the C source or is some of this translated
euphoria code? If it is a problem with the compile in the C source, has that
changed since 2.4? (I have no problems with any of that in 2.4 on the
Zaurus.)
If I remove all compiler optimisations, the resulting interpreter seg faults
immediately.
Mark
5. Re: Compiling Euphoria 3+ for non-x86 targets
I was actually just thinking about how nice it would be to use euphoria on
various RISC processors. I would love to have a pocket computer with Euhporia on
it. 
Unfortunately, I don't know enough about C and Assembly to port Euphoria to
another platform. 
I keep thinking about trying though...
~Ryan W. Johnson
Fluid Application Environment
http://www.fluidae.com/
[cool quote here, if i ever think of one...]
6. Re: Compiling Euphoria 3+ for non-x86 targets
Mark Brown wrote:
> Matt wrote:
> > Now that we've got everything in subversion, we have a detailed diff
> record
> > of what has changed. You can get these through svn commands.
>
> Thanks for the info Matt. I probably should have checked the list archive
> for that before posting... haven't read the list much of late.
>
> Regarding the seg fault I'm getting, I've tracked it down to symtab.e in
> procedure InitSymTab(). Specifically the crash occurs at the line "while
> SymTab[s][S_SAMEHASH] != 0 do"
You aren't very far into the interpreter initialization.
The fact that it crashed at that line doesn't give
me any clues.
> That line doesn't look weird in any way to me, except that I think it is the
> first instance of a "while" being used in the eu code. I'm a bit scared of
> that as I'm guessing that means that my compiled eu while loops are broken.
That probably isn't the problem.
I'd be more worried about maybe the storage
allocation system (i.e. malloc()). I make some dirty assumptions
about how C's malloc() works internally on each platform.
> Rob, could you perhaps point me in a direction to look for this. Is this
> sort of thing all still in the C source or is some of this translated
> euphoria code? If it is a problem with the compile in the C source, has that
> changed since 2.4? (I have no problems with any of that in 2.4 on the
> Zaurus.)
>
> If I remove all compiler optimisations, the resulting interpreter seg faults
> immediately.
The front-end is now all Euphoria code, so you have
to translate it to C, before porting the front-end and back-end
C files to a new platform. The translation should be done on a
platform similar to the one you are porting to.
It sounds like you've done all that. I doubt that there
are bugs in the translation of simple constructs like "while".
I'd be more worried about differences in the C run-time code
between the two platforms. i.e. malloc(), and the start-up code
for translated programs. I also wonder if C global data is initialized
to 0, like it is on Linux. I might have used that fact in a few places,
though I generally try not to assume that.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Compiling Euphoria 3+ for non-x86 targets
I wrote:
> Regarding the seg fault I'm getting, I've tracked it down to symtab.e in
> procedure InitSymTab(). Specifically the crash occurs at the line "while
> SymTab[s][S_SAMEHASH] != 0 do"
Furthur to that, I've narrowed this down to the translated C code. The
segfault happens at "RefDS(_1144);" in symtab.c and doesn't seem to have
anything to do with the 'while'. RefDS is in execute.h as "#define RefDS(a)
++(DBL_PTR(a)->ref)" and this is the same as 2.4. There must be a bad
pointer but I can't work out why. Nothing relevent seems to have changed in
the source since 2.4.
Sorry for thinking out loud on this. If anyone has had a similar problem,
let me know
Mark
8. Re: Compiling Euphoria 3+ for non-x86 targets
Robert Craig wrote:
> You aren't very far into the interpreter initialization.
> [snip]
I'm now beginning to think that I've made a mistake in converting those
instances of '$' in the front-end eu source to make it work with my 2.4
interpreter, perhaps when copy pasting (I make a *lot* of mistakes!)
So I tried translating the eu source to C on my linux pc, then copied the 21
C files it created over to the zaurus, commented out the line in imakeu on
the zaurus which usually does the translation and executed imakeu.
Unfortunately, this gives a ton of undeclared references (to variables etc?)
when compiling (sorry if my terminology is wrong here.) I think this is how
I got a working compile for 2.5 on my Z last time. What am I doing wrong? (I
would use the 2.5 Z interpreter to do all this except it had broken shared
lib functionality so I never kept it on my Z and several hard drive failures
later, I no longer seem to have the source...)
This also leads me to a question. I've got a working 2.4 interpreter on my Z
to do this (assuming I made the mistake with '$', I'm sure I can get this to
work that way,) but how would one compile euphoria for a completely new
system without the benefit of an earlier, C only version of the eu source?
Mark
9. Re: Compiling Euphoria 3+ for non-x86 targets
Ryan wrote:
> I was actually just thinking about how nice it would be to use euphoria on
various RISC processors. I would love to have a pocket computer with
Euhporia on it.
I use my Zaurus more than my laptop these days. It's got a full vga display
(very crisp,) a fully functional and surprisingly usable keyboard, firefox
browser (via wifi card) etc, etc. What I really love though is using eu on
it. I like to tinker as a programmer (not good enough to do anything but,
I'm afraid) and the Z is great for that.
> Unfortunately, I don't know enough about C and Assembly to port Euphoria
to another platform. I keep thinking about trying though...
I'm lousy at both C and assembler but managed to get Eu 2.4 to compile quite
easily. A basic interpreter really only required that certain things be
#ifdef'ed out so that the compile would work. For example, mouse support is
not available on the Z but was assumed for linux in 2.4. The compile itself
is even easier now as Rob changed the way that was handled. The tricky part
is the small amount of assem code. My way of doing that for ARM assem was...
really dodgy (my programmer brother in law confirmed that for me!) but was
the only way I could get it to work. I'm going to be embarrased to show that
code but at least an ARM guru will be able to fix it now that everything is
open source.
What target system would you be compiling for?
Mark
10. Re: Compiling Euphoria 3+ for non-x86 targets
Robert Craig wrote:
> > You aren't very far into the interpreter initialization.
> > [snip]
>
> I'm now beginning to think that I've made a mistake in converting those
> instances of '$' [snip]
I found my compile of 2.5 and did a semi-successful translate/compile of 302
with that on the Zaurus. I also worked out why my translated code from my
linux pc wouldn't work (paths at the beginning of the c headers pointing to
the path on my pc, not to where the files are on the zaurus) so that is a
workable option too.
Some of the eu demos work under 302. However, anything to do with file
opening gives a "Fatal run-time error: bad file number (2072013185)" or
similar, then seg-faults. The 2.5 compile (front-end translated on the pc)
works ok. Very strange.
Mark
11. Re: Compiling Euphoria 3+ for non-x86 targets
Mark Brown,
Unless I misunderstood you, you said that you lost the source of your
old port yet you still have the binary. Since 3.0 the Euphoria Interpreter
is available as a program itself. You might be able to use bind in 3.0
to create the 3.0 interpreter using the 2.4 interpreter. Does that make
sense?
So, if you have a setup like this:
/euphoria-2.4/...
/euphoria-3.0/...
The euphoria-2.4 directory contains the binary you ported
with I assume the support files and euphoria-3.0 containing a linux or
windows distribution of the Euphoria Interpreter and support files.
I know, what your thinking... and your right. You can't run windows or
linux binaries on the machine you are porting this to. But you can call
You make sure your environment is setup for /euphoria-2.4/, the
PATH and EUDIR variables set for the 2.4. That is,
you just copy the directory structure of /euphoria-3.0 over from an
Intel based computer you don't actually run the install and You don't
change EUDIR to this new 3.0 -- yet.
Now you should be able to run many 3.0 programs.
/euphoria-2.4/bin/ex /euphoria-3.0/bin/eu.ex /euphoria-3.0/bin/bind.il <place
bind building arguments here>
Before you do you will have to port eu.ex to 2.4: change $
to length() and there is a program that will do that for you in the archive
somewhere. Then port I think it is safer than doing it manually.
Shawn Pringle
12. Re: Compiling Euphoria 3+ for non-x86 targets
Shawn Pringle wrote:
> Unless I misunderstood you, you said that you lost the source of your
> old port yet you still have the binary [snip]
Hi Shawn. Sorry for the slow reply and thanks for the suggested work around.
As it stands, I actually seem to have created a mostly working version of
the 3.0.2 interpreter for my Zaurus. In the end I have had to translate the
front-end on my Linux PC, copy the translated files to my Zaurus and then
compile the interpreter from there. If I do it this way the seg-faults
disappear in the resulting interpreter. If I then use that working
interpreter to create a new set of translated front-end C files and
recompile, the resulting interpreter seg-faults, just as it does if I use my
2.5 Zaurus compile to do the translation!
It seems that my 2.5 and 3.0.2 Zaurus interpreters produce different
translated front-end C code to the official interpreter on my Linux laptop.
I assume that they should produce exactly the same output. I've only
compared the Zaurus and PC translated files for size. Some of the files are
exactly the same size, others slightly or very different. Both the Zaurus
and PC translated code compiles fine though. I'm going to have to do a side
by side comparison of the translator output, although I may not learn
much... I'm reaching the limits of my skills pretty fast :). There is
obviously more I need to do to create a reliable port.
Mark
13. Re: Compiling Euphoria 3+ for non-x86 targets
Mark Brown wrote:
> Hi Shawn. Sorry for the slow reply and thanks for the suggested work around.
> As it stands, I actually seem to have created a mostly working version of
> the 3.0.2 interpreter for my Zaurus. In the end I have had to translate the
> front-end on my Linux PC, copy the translated files to my Zaurus and then
> compile the interpreter from there. If I do it this way the seg-faults
> disappear in the resulting interpreter. If I then use that working
> interpreter to create a new set of translated front-end C files and
> recompile, the resulting interpreter seg-faults, just as it does if I use my
> 2.5 Zaurus compile to do the translation!
>
> It seems that my 2.5 and 3.0.2 Zaurus interpreters produce different
> translated front-end C code to the official interpreter on my Linux laptop.
> I assume that they should produce exactly the same output. I've only
> compared the Zaurus and PC translated files for size. Some of the files are
> exactly the same size, others slightly or very different. Both the Zaurus
> and PC translated code compiles fine though. I'm going to have to do a side
> by side comparison of the translator output, although I may not learn
> much... I'm reaching the limits of my skills pretty fast :). There is
> obviously more I need to do to create a reliable port.
It would be interesting to know exactly what the differences are.
On Linux, you can use:
diff -r dir1 dir2
to compare two directories.
On Windows, you can use something like:
fc dir1\*.c dir2\*.c
to compare a bunch of files.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
