Short: Mozilla JavaScript interpreter - src Author: mozilla.org (The Mozilla Foundation) Uploader: alexandre balaban fr (Alexandre Balaban) Type: dev/lang Version: 1.5-1 Replaces: SpiderMonkey-js-src.lha Architecture: generic Distribution: Aminet This is my port of Mozilla's open-source "SpiderMonkey" JavaScript interpreter. This is the source code. See the binary package for a pre-built executable. The 68k Amiga port have been done using SAS/C 6.58. Thus the build system requires sc, smake, and slink. Using the GNU tools gcc, make, and ranlib will not work for 68k currently. The Amiga OS4 port have been done using SDK v51.22, using GCC tools. SpiderMonkey is generally intended to be used as a shared library and embedded in other applications, but it comes with a command-line interpreter for testing and learning. That is what is included here. Example (interactive): 6.Fad:Dev/js/src> js js> myDate = new Date(); Wed Nov 22 2006 11:55:31 GMT+0000 js> myDate.toLocaleString(); Wed Nov 22 11:55:31 2006 js> quit() Example (command): 6.Fad:Dev/js/src> js myfile.js (or, to include some startup code before running myfile:) 6.Fad:Dev/js/src> js -f shell.js myfile.js It would be entirely possible to create a javascript.library using the SpiderMonkey source code, offering a JavaScript interpreter to any Amiga application. I am not enough of a guru to do this yet. :) If a knowledgable someone would like to work on this, please contact me. "Features" of this Amiga version (17 Dec 2006): - currently no file support - currently no support for passing arguments using Workbench (recommended to run from CLI) - compiled for 68020+FPU using SAS/C 6.58 (non-FPU binary might be possible) - compiled for PPC Amiga OS4 using SDK v51.22 - requires a stack size >= 50000, but I have not inserted the code to enforce this and have not turned off SAS/C's stack checking (but have not enabled automatic stack growth, either) - passes all the same ECMA JavaScript tests on Amiga as it does on other platforms, with a few very minor exceptions (MAX_FLOAT is a tiny bit smaller, and a call to Date() might not have the same second as the next call to Date(), but this makes sense and is no problem) - tested on A4000T/060-50/64mb/OS 3.5 and A1200/030/8mb/OS 3.0 - tested on A1XE/G4-800/512mb/OS4upd4 Notes (17 Dec 2006): - the 68k part did not evolve since the 22 Nov 2006. Notes (22 Nov 2006): - to quit, enter "quit()" and press return - build instructions for my dumb build system are in the readme included with the source code package, in case you want to compile this yourself References (22 Nov 2006): Mozilla's JavaScript projects: http://www.mozilla.org/js/ SpiderMonkey JavaScript: http://developer.mozilla.org/en/docs/SpiderMonkey SpiderMonkey command-line interpreter: http://developer.mozilla.org/en/docs/Introduction_to_the_JavaScript_shell Source code notes: Before you can build the JavaScript engine, you must build the fdlibm library. It is included here in the fdlibm/ directory. - For 68k, just typing "smake" in there should work (there is a SAS/C makefile there). You will still need to run OML manually. Instructions are included there. - For AmigaOS 4, just typing "make -f makefile.os4" should do the work, note that objects and binaries are generated in special drawers to separate them from 68k build : you'll find binary in binAOS4 and objects in objAOS4. Also this makefile should be usable in a cross compilation environnement. Then come back here to the main directory, - For 68k, type "smake" and watch as it builds the JavaScript core. - For AmigaOS 4 just type "make -f makefile.os4" and wait a moment. A couple of notes: - For 68k I am not using any GNU tools here! Do not expect to use GNU make or GNU cc and have good results! That is not how I have done this port. This port uses sc, smake, and slink. However, now that the AmigaOS 4 port uses GCC theorically it should be easy to create 68k GCC makefiles... - all floating point code uses fdlibm to retain compatibility with the expectations of the JavaScript code. This is probably must slower than using native floating point code, but it must be done this way. - For 68k, I have a couple of special files involved in the build process. "script" in the main source directory is the set of commands for slink. "objs" in the fdlibm directory is the set of object files to pass to OML. Why am I doing things this way? Because I am dumb. - "jscpucfg" is a standalone executable for generating the "jscpucfg.h" file. It is not a part of building the greater JS code.