Trying to build TinyJS for the Prop.
Heater.
Posts: 21,230
I have been trying to compile a tiny JavaScript interpreter with propgcc and SimpleIDE. It's from here.: http://code.google.com/p/tiny-js/
It builds and run fine on my Debian box. Then I hacked it around a bit to make it more Prop friendly. Removing use of exceptions for example.
Actual compilation goes fine. The executable is about half a meg so I use an XMM setting, hoping it might run on my SDRAM board some time.
Linking fails.
Here is a compilation step:
What to do?
It builds and run fine on my Debian box. Then I hacked it around a bit to make it more Prop friendly. Removing use of exceptions for example.
Actual compilation goes fine. The executable is about half a meg so I use an XMM setting, hoping it might run on my SDRAM board some time.
Linking fails.
Here is a compilation step:
propeller-elf-c++ -I . -L . -Os -mxmmc -Wall -fno-exceptions -Dprintf=__simple_printf -fno-rtti -std=c99 -c TinyJS.cpp -o xmmc/TinyJS.opp cc1plus: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ [enabled by default]Which goes OK. Here is what the linker says:
/opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `.addinfA': (.text+0x1b8): relocation truncated to fit: R_PROPELLER_23 against `__return_nan' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `__mul_excep': (.text+0x210): relocation truncated to fit: R_PROPELLER_23 against `__return_nan' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `__mul_excep': (.text+0x21c): relocation truncated to fit: R_PROPELLER_23 against `.mulzeroA' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `__mul_excep': (.text+0x228): relocation truncated to fit: R_PROPELLER_23 against `.mulinfA' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `__mul_excep': (.text+0x234): relocation truncated to fit: R_PROPELLER_23 against `__return_signed_zero' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `__mul_excep': (.text+0x23c): relocation truncated to fit: R_PROPELLER_23 against `__return_signed_infinity' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `.mulzeroA': (.text+0x248): relocation truncated to fit: R_PROPELLER_23 against `__return_nan' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `.mulzeroA': (.text+0x250): relocation truncated to fit: R_PROPELLER_23 against `__return_signed_zero' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `.mulinfA': (.text+0x25c): relocation truncated to fit: R_PROPELLER_23 against `__return_nan' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `.mulinfA': (.text+0x264): relocation truncated to fit: R_PROPELLER_23 against `__return_signed_infinity' /opt/parallax/lib/gcc/propeller-elf/4.6.1/xmmc/libgcc.a(_loadfloat.o): In function `___divsf3': (.text+0x28c): additional relocation overflows omitted from the output collect2: ld returned 1 exit status Done. Build Failed!
What to do?
Comments
If I try to build this for LMM it complains I am half a meg over the top, so that's not so bad.
The guy(s) who wrote TinyJS have it running on ARMs with only 128K FLASH and 20K RAM.
Try XMM-SINGLE mode? XMMC uses HUB for data and that may be exceeded with C++.
No change I'm afraid:
$ hg update default --clean $ hg branch default $ ./rebuild.sh if [ -r syslex.c ]; then \ gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -Wno-error syslex.c ; \ else \ gcc -c -I. -I../../../propgcc/binutils/binutils -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -Wno-error ../../../propgcc/binutils/binutils/syslex.c ;\ fi syslex.l:31:21: fatal error: sysinfo.h: No such file or directoryDebian wheezy 64 bit.
seems
char *strdup(const char *source) from string.h
is missing ?
I use this version of propeller-elf-gcc:
Using built-in specs.
COLLECT_GCC=propeller-elf-gcc
COLLECT_LTO_WRAPPER=/home/knoppix/SimpleIDE-0-7-2/parallax/bin/../libexec/gcc/propeller-elf/4.6.1/lto-wrapper
Target: propeller-elf
Configured with: ../../propgcc/gcc/configure --target=propeller-elf --prefix=/opt/parallax --disable-nls --disable-libssp --disable-lto --with-pkgversion=propellergcc_v0_3_4_1483 --with-bugurl=http://code.google.com/p/propgcc/issues
Thread model: single
gcc version 4.6.1 (propellergcc_v0_3_4_1483)
best regards
Reinhard
The C compiler itself actually works around this in XMM mode by inserting a short branch around the jump instead of relying on the jmp data turning into a no-op. Maybe we have to do that in lib1funcs.asm too.
For now you may be able to work around it by replacing all .text directives in lib1funcs.asm with .section .hubtext, "ax" and recompiling. Let me know if that helps.
Eric
Eric, I'll get on to that later. My dev machine is tied up with farmville just now:(
Wow! That must be interesting to be a developer for FarmVille!!! You must have lots of friends!!
Once they are addressed tiny-js builds no problem with the default branch.
There is still the matter of making it "embedded" though.
My files are attached for an easy fix.
string.h should replace ${PROPGCC}/propeller-elf/include/string.h
stat.h should replace ${PROPGCC}/propeller-elf/include/sys/stat.h
${PROPGCC} is your Propeller-GCC install path.
Solve the header issues like this:
Function strdup is in the library, but the declaration is missing from string.h.
Add it here ${PROPGCC}/propeller-elf/include/string.h
char * strdup (const char *s1);
File sys/stat.h is missing the C++ wrapper. Add it after #include <sys/types.h>
#if defined(__cplusplus)
extern "C" {
#endif
// add this before the last #endif
#if defined(__cplusplus)
}
#endif
OK I'll have a go at that now.
I can't build the default branch anymore. See post #9 above.
Hi Heater,
Looks like we can squeeze these two fixes into the next build(s) that David uploads.
I'm testing builds with those changes now and will post them to both branches after some sanity checks.
Do you have diffs or maybe a project clone for Propeller? With exceptions, i get 600KB of code
Thanks,
--Steve
I think that's a Debian Wheezy problem; I don't think we've ever been able to build there (or at least I can't). p2test has a newer version of binutils now, and they've fixed the build.
Eric
I have put up tiny-js-propeller on github:
https://github.com/ZiCog/tiny-js-propeller
Only changes so far are to crudely comment out the try/throw/catch stuff. Any errors in JS and the Script just dies now. Also added my .side file.
In the original svn repo there is a branch that tries to make the thing more ECMAScript compliant. It's over 8000 lines of code so is even bigger and I guess we don't want to go there. Besides I cold not get it to compile. That branch is not in my repo.
I can add you as a collaborator if you have a gihub account.
I now have the default branch of propgcc working on Debian Wheezy, pulled last night, and I still can't compile tinyjs. Still get those floating point related errors.
The question is, how to set it up to run javascript on Propeller? Use a simple monitor?
http://www.youtube.com/watch?v=Mk3qkQROb_k
Java is not sexy anywhere. And here is a cool dude to explain why:
http://www.youtube.com/watch?v=FJ7QsEytQq4
JavaScript is a whole different, and superior, language.
Although some would doubt the sanity of node.js
http://www.youtube.com/watch?v=bzkRVzciAZg
Bah, wah, this is not fair!. I cannot compile tiny-js with the latest default propgcc or the p2test branch.
If Script runs on the Prop then we only need to cut and paste a JS program into the the serial terminal and it will run. at least that would be a start.
Did I say we needed a JS editor in SimpleIDE?
Javelin Java (1.1) was ported to Propeller years ago in SPIN and PASM and performed better than ZOG in some tests
It could also run programs from EEPROM although slower than normal. At this time the compiler support seems to be broken though.
I never had time or any earnest mandate to try porting Java 2. I do have a Java2 book for that purpose donated from a school.
I tried your hack to lib1funcs.asm to build tiny-js with p2test. It did not work:
I'll try to fix this; it may take a day or two. Thanks for bringing this to our attention!
Eric
It wasn't as bad as I thought, so the fix is checked in to the p2test branch. tiny-js compiles now, to a huge program with 651700 bytes of text. I don't know if it actually runs though, I wasn't brave enough to try it :-).
One word of warning if you want to try it: the latest p2test branch also has a modified assembler that uses some of Jac's ideas to improve PASM compatibility. Instead of the .cog_ram directive there's a .pasm directive which causes addressing to be done in longs instead of bytes. This will only affect hand-written assembly that uses .cog_ram, and in many cases just changing ".cog_ram" to ".pasm" will work, but the semantics are slightly different. On the plus side, you can feed ASCII .spin files to gas now if you give it the --pasm option (or edit the .spin file to add .pasm at the top). Sometimes they even assemble correctly!
Eric
You bounder! Well done.
@Eric,
Just finished rebuilding p2test again. Yes! It now builds TinyJS. You really are turbo. Now I have to run to work where my Propeller gear is and see if it runs.
We have some issues here:
TinyJS is huge! Jazzed's screen shot shows 800KBytes. I get nearly 700KBytes(-Os helps). We only have 3000 lines of code here so this is seriously bloated. God knows how Pur3 gets it down to 128K FLASH and 20K RAM.
Of course it is making use of <string>, <sstream> and <vector>. Can I assume that pulls in a lot of junk we don't need.
Those 64 bit doubles do not help but I can't see JS working with only 32 bit floats.
I don't see any mention of an event loop in the interpreter, that's not good.
Seems adding functions for tweaking pins and accessing other Prop features is easy enough.
I can't build propside with Spin support any more. When running the release script it fails to find the headers for quazip.
I copied those headers to the propside source directory and things proceeded until: /usr/bin/ld: cannot find -lquazip
Some how I managed to do this a few days ago, now what did I do then...?
Anyway, now I find my GadgetGanster Prop hardware is not in the office after all...now what did I did with it...?