1. Compiling Euphoria 3+ for non-x86 targets
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 11, 2007
- 537 views
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
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 11, 2007
- 546 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 11, 2007
- 515 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 13, 2007
- 501 views
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
- Posted by Ryan W. Johnson <ryanj at fluidae.com> Mar 13, 2007
- 520 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 13, 2007
- 504 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 13, 2007
- 526 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 14, 2007
- 527 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 14, 2007
- 523 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 15, 2007
- 518 views
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
- Posted by Shawn Pringle <shawn.pringle at gmail.com> Mar 17, 2007
- 531 views
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
- Posted by "Mark Brown" <mabrown at ihug.com.au> Mar 24, 2007
- 521 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 25, 2007
- 523 views
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