Hi all,

Not sure to post this in 8 or 32 bit, but as the latter had no posts yet I thought I'd go first.

As shown here I'm porting a scheme interpreter to Sprow's ARM7 board using yagarto.

I'm in the process of adding the standard OSxxxx calls we all know and love as primitives to the language, but also pondering if I can't get even more "primitive" by exposing swi itself to the interpreter. I haven't thought of a nice API though.

Anyway, while implementing OSWORD I decided to create a dispatch because of the different control block sizes and meanings. It's becoming quite unruly though as I'm dynamically allocating control block space each time according to the specification of the osword call.

Can I presume an OSWORD control block is at most 256 bytes on a BBC? I.e. could I get away with allocating a static memory block of 256 bytes which I'd use as the standard osword control block space?

I think this would both simplify things and enhance performance because it eliminates heap allocation overhead. The translation of the control block can then be implemented as a cast of the control block to a particular C struct.

Slightly OT: Would anybody be interested in a source release of this interpreter? If so, would it be one for the retrosoftware repository?

From the details I can remember, and those I can (quickly) look up - "yes"; Acorn "Application Note #004" (the TUBE support document - available, with others, off Chris's Web site) contains some details that may be of relevance.

--Martin

Thanks for the reference!

I was aware of the application note, but didn't figure it contained the information I wanted.

Anyway, I went another route. Instead of the osword dispatch I partly implemented "bytevectors" which are essentially the scheme equivalent of raw binary data. This means I can control the block size by manipulating the size of the bytevector. This reduced the code size to a relatively simple osword handler and immediately exposed all available oswords generically. (see screenshot for examples)

Next on the list are a native text editor, a socket library for the ethernet card, some way to do fast data transfer over the tube to manipulate the screen and perhaps a datacentre api.

Any help would be appreciated

I'm cleaning up the code some more and then I guess I'll post the sources somewhere. I think it now contains quite a lot of interesting stuff for those who want to develop in C for the ARM7 (or even those interested in using scheme/lisp).