I have just put a new directory called "embedded" in the CSL part of the tree. It has 47 C source files and 17 C header files, and you compile things by merely compiling all the sources together. If you can manage that (and it is tolerably close to being conservative if 32-bit specific C code) you can run the resulting executable with the ready-supplied reduce image file and have a version of the code that was VERY quick to build but does not have a GUI or even prompts. If you want to run Reduce on your set-top box, wristwatch or whatever this may give you an easy place to start your hacking from. I bet it still has plenty of things that are really not very portable etc, but is is there as a basis for hacking not as a neat and finsihed "product". Enjoy. Arthur
I gave this a go on an ARM board (actually the new copro for the BBC). This basically has a very minimal RISCOS implementation with no memory management. When I compile it using ARM gcc (yagarto), it starts complaining about not finding the include file for dynamic linking (in fasl). Which does not really surprise me of course.
Does this mean this will only work on a more elaborate embedded OS?
I have run the system on top of Linux on a linksys router, and on an ipaq 4700 (in each case a year or so ago). Many years ago the code probably started on an ARM co-processor or maybe it was late enough that it was a prototype Archimedes. But any such platform is liable to mean you have to do a bit of hacking! The main-line versions these days assume you have the somrt of amounts of memory that "real" machines usually have. To run on smaller machine (the router I used was the one with 32Mb) I changed the PAGE_BITS definition down rather a lot.
dlfcn.h is included so that I can use dlopen (etc) for what is really an experiment in native compilation. If you kill it and all that depends on it you should still be safe.
Is there a reasonable simulation environment for the ARM that I could use to try this? As per my original post the embedded folder is a starting point not a guaranteed tidy version, and it is now rather a long time since I have worked with ARMs even though that was my main platform for many years. One challenge from old Riscos days was a rigid limit on the number of files you could have in a single directory - I hope that is not longer an issue.
So really the situation is that HISTORICALLY this all ran on ARM/riscos and there is not huge reason why on hacking out some bits it should not do so again - and I will help if I can!
I haven't really found a comparable simulation environment, but I guess something like QEMU would work. I'm trying to get a native C compiler going which "should" mean writing the GCC newlib stubs to be able to use the stdio and math libraries. However all memory management and process stuff is not available. This particular cross compilation on yagarto was just to try and see what happens. Obviously it complains about the missing newlib stubs, but the dlfcn errors stopped me dead for now.
B.t.w. this is only a private project to see if I can get it running. Obviously there are better choices to run "seriously"
It has been a while but I'm still at it.
It seems that with lots op help from others it looks like I've got a reasonably good "newlib" with some memory management thrown in. I can more or less get a UMB scheme going.
When I now do a "make" on the embedded CSL I get loads of these messages during link phase
./o/arith02.o: In function `timesib':
arith02.c:(.text+0x8c4): undefined reference to `C_nil'
B.t.w. the same person who's done the newlibs has made an ARM7 simulation available in a bbc emulator. It looks like this could be a good testing target.
C_nil is defined on about line 227 of restart.c, so the linker SHOULD find it!
If there is any real chance of an emulation environment that would be close enough to make it possible for me to join in please email me idio-proof details of what to download from where and how to set it up and I may have a play.
Log in to post a comment.