Folks,
Has anyone done an estimate (or measurement!) of the resources required on the target platform to do a port of Gambit? For example, for a given processor architecture, what are the memory requirements to support a port of the interpreter for code, stack space, data RAM, etc. Other HW resources and functional support?
I have in mind the types of processors currently used by "embedded systems", which tend to have lots of processor power, but either simple and small memories or rather baroque memory architectures (e.g., a mixture of ROM, fast and slow RAM, writeable FLASH, etc.) and no VM support or rotating storage.
It would be nice to get some "lessons learned" feedback from Gambit porters before charging down a blind alley myself :-)
Mike Wirth Palo Alto, CA
Afficher les réponses par date
If you're interested in embedded systems, you may want to have a look at Picobit, a Scheme written specifically for small embedded systems: http://repo.or.cz/w/picobit.git
Marc and I wrote a paper talking about the system. It's available here: http://www.ccs.neu.edu/home/stamourv/picobit.pdf
Picobit has been used on PIC18 microcontrollers and on x86, but since it's written in portable C, it could run pretty much anywhere.
Vincent
At Thu, 16 Sep 2010 19:07:17 -0700, Michael Wirth wrote:
Folks,
Has anyone done an estimate (or measurement!) of the resources required on the target platform to do a port of Gambit? For example, for a given processor architecture, what are the memory requirements to support a port of the interpreter for code, stack space, data RAM, etc. Other HW resources and functional support?
I have in mind the types of processors currently used by "embedded systems", which tend to have lots of processor power, but either simple and small memories or rather baroque memory architectures (e.g., a mixture of ROM, fast and slow RAM, writeable FLASH, etc.) and no VM support or rotating storage.
It would be nice to get some "lessons learned" feedback from Gambit porters before charging down a blind alley myself :-)
Mike Wirth Palo Alto, CA _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 2010-09-16, at 10:07 PM, Michael Wirth wrote:
Folks,
Has anyone done an estimate (or measurement!) of the resources required on the target platform to do a port of Gambit? For example, for a given processor architecture, what are the memory requirements to support a port of the interpreter for code, stack space, data RAM, etc. Other HW resources and functional support?
I have in mind the types of processors currently used by "embedded systems", which tend to have lots of processor power, but either simple and small memories or rather baroque memory architectures (e.g., a mixture of ROM, fast and slow RAM, writeable FLASH, etc.) and no VM support or rotating storage.
It would be nice to get some "lessons learned" feedback from Gambit porters before charging down a blind alley myself :-)
To my knowledge recent versions of Gambit have been compiled on the following embedded systems:
- Nintendo DS (ARM CPU, 4 MB RAM) - Linksys WRT54GL (MIPS CPU?, 16 MB RAM) - iPhone/iTouch (ARM CPU, 128 MB RAM) - Xilinx Virtex II FPGA (PowerPC CPU, a few MB of RAM)
Search the Gambit mailing list archive for details.
Gambit was designed to be extremely portable. It has very few library dependencies (libc is enough to have a working system). In the words of the author of the Linksys port (http://weblambdazero.blogspot.com/2008/08/scheme-termite-erlang-alternative....):
"On the other hand, a great advantage of Gambit-C over Erlang is that it can translate Scheme applications to plain C, which than can be compiled to standalone executables using gcc. Thanks to this feature I managed to compile a few Gambit examples with OpenWRT-SDK and ran it on my home Linksys WRT54GL router with OpenWRT firmware - the only thing I had to do was to replace gcc command with mipsel-linux-gcc while compiling gsc output files."
If Gambit does not compile on your target platform, then please report this to me or the Gambit mailing list.
Marc
----- Original Message ----
From: Marc Feeley feeley@iro.umontreal.ca
To my knowledge recent versions of Gambit have been compiled on the following embedded systems:
- Nintendo DS (ARM CPU, 4 MB RAM)
- Linksys WRT54GL (MIPS CPU?, 16 MB RAM)
- iPhone/iTouch (ARM CPU, 128 MB RAM)
- Xilinx Virtex II FPGA (PowerPC CPU, a few MB of RAM)
Search the Gambit mailing list archive for details.
Gambit was designed to be extremely portable. It has very few library dependencies (libc is enough to have a working system).
I think all these system have a MMU. Can Gambit run on a no-MMU system?
I'd like to propose Gambit for a project based on ucLinux on a Renesas SH7203. AFAIK, ucLinux's malloc() uses mmap() instead of brk(), it is a iusse wrt memory management?
Thank in advance for experiences reports and suggestions.
--marco
On 2010-10-07, at 5:33 AM, Marco Benelli wrote:
----- Original Message ----
From: Marc Feeley feeley@iro.umontreal.ca
To my knowledge recent versions of Gambit have been compiled on the following embedded systems:
- Nintendo DS (ARM CPU, 4 MB RAM)
- Linksys WRT54GL (MIPS CPU?, 16 MB RAM)
- iPhone/iTouch (ARM CPU, 128 MB RAM)
- Xilinx Virtex II FPGA (PowerPC CPU, a few MB of RAM)
Search the Gambit mailing list archive for details.
Gambit was designed to be extremely portable. It has very few library dependencies (libc is enough to have a working system).
I think all these system have a MMU. Can Gambit run on a no-MMU system?
I doubt that the Nintendo DS has an MMU. Gambit has no reliance on an MMU. In fact, for portability, all dynamic memory allocation (of heap blocks, including the stack) is done with malloc/free. So as long as your C compiler supports malloc/free you are OK.
I'd like to propose Gambit for a project based on ucLinux on a Renesas SH7203. AFAIK, ucLinux's malloc() uses mmap() instead of brk(), it is a iusse wrt memory management?
iusse?
I checked the specs for the Renesas SH7203 development board and it has a 16MB SDRAM module. That should be plenty for the heap. On the other hand, the development board has a 4MB FLASH memory, for the bootloader and OS (ucLinux) and user code (2MB total). On an intel processor when compiled with gcc, the Gambit interpreter's code occupies 3 to 4 MB. The C compiler for the SH7203 may generate more compact, or less compact code, so YMMV. If the program is still too big, you can probably reduce the size by eliminating some of the runtime functions (file I/O, bignums, etc). On the other hand, if the target platform has more FLASH memory, say at least 8MB, then you wouldn't have to change anything. You might also be able to run "on the bare metal", i.e. no OS at all, to access the full 4MB of FLASH.
Marc
-
Marc Feeley -
Marco Benelli -
Michael Wirth -
Vincent St-Amour