FCode on an embedded Leon-Sparc system

[Rolf Schroedter]

For a scientific space project I'm thinking about including an FCode 
interpreter into the onboard software.
The target system is a Leon3 processor (Sparc-V8) in FPGA with serial 
port(s), spacewire and a few other interfaces.
I'm able to compile & run bare C applications (gcc cross-compiler), so 
it seems to me that I don't need a real BIOS.

Having some experience with Forth I would like to include a FORTH 
interpreter for
- interactive hardware implementation & testing via the serial port
- executing FORTH code (precompiled bytecode ?) via telecommands during 
flight.

Ideally the complete FORTH system should be in the range of 32-40 kBytes...
I'm completely new to OpenBios & FCode. Any suggestions are appreciated:
- where to start
- how to strip down the OpenBios code
- etc.

Thanks & regards,
Rolf.

[Blue Swirl]

> For a scientific space project I'm thinking about including an FCode
> interpreter into the onboard software.
> The target system is a Leon3 processor (Sparc-V8) in FPGA with serial
> port(s), spacewire and a few other interfaces.
> I'm able to compile & run bare C applications (gcc cross-compiler), so
> it seems to me that I don't need a real BIOS.

So you probably won't need SCSI or floppy drivers or any of the filesystems. 
These can be disabled by editing config/examples/cross-sparc32_config.xml. 
What kind of serial port is this, Zilog or PC (16550)?
> Ideally the complete FORTH system should be in the range of 32-40 kBytes...

That can be difficult to achieve, currently the full build is 150k C code + 
100k Forth. I don't know how much of the Forth is needed. Taking out 
unwanted drivers etc. could help a lot on C side, but down to 30-40k?

_________________________________________________________________
Be seen and heard with Windows Live Messenger and Microsoft LifeCams 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://www...

[Rolf Schroedter]

Blue Swirl wrote:
> > For a scientific space project I'm thinking about including an FCode
> > interpreter into the onboard software.
> > The target system is a Leon3 processor (Sparc-V8) in FPGA with serial
> > port(s), spacewire and a few other interfaces.
> > I'm able to compile & run bare C applications (gcc cross-compiler), so
> > it seems to me that I don't need a real BIOS.
>
> So you probably won't need SCSI or floppy drivers or any of the filesystems. 
> These can be disabled by editing config/examples/cross-sparc32_config.xml.

Thanks, I'll try to disable them.
> What kind of serial port is this, Zilog or PC (16550)?

None of the above, a special serial interface integrated into the processor.
You can simply assume, that  stdin/stdout are connected to the serial 
port at main() startup.
> > Ideally the complete FORTH system should be in the range of 32-40 kBytes...
>
> That can be difficult to achieve, currently the full build is 150k C code + 
> 100k Forth. I don't know how much of the Forth is needed. Taking out 
> unwanted drivers etc. could help a lot on C side, but down to 30-40k?

Really that large ? I don't have experience with 32-bit Forth'es. 16-Bit 
systems usually have a small footprint.
Okay, I have a 64 KByte PROM, and I forgot that the code could be 
compressed, perhaps a FCode interpreter for ~64 kByte could do it...

Thanks & regards,
Rolf.

[Segher Boessenkool]

> > Ideally the complete FORTH system should be in the range of 32-40  
> > kBytes...
>
> That can be difficult to achieve, currently the full build is 150k  
> C code +
> 100k Forth. I don't know how much of the Forth is needed. Taking out
> unwanted drivers etc. could help a lot on C side, but down to 30-40k?

Most Forth systems can be stripped to (much) less than 8kB, so
32kB is definitely achievable; it all depends on how much, and
what, functionality you want.

Rolf, since you said you can already run "bare" C code and you
don't need a "BIOS", you're probably better off using a normal
Forth system on your machine, and save yourself the work of
stripping OpenBIOS until it is what you want.

Segher

[Rolf Schroedter]

Segher Boessenkool wrote:
> Rolf, since you said you can already run "bare" C code and you
> don't need a "BIOS", you're probably better off using a normal
> Forth system on your machine, and save yourself the work of
> stripping OpenBIOS until it is what you want.

For the development phase I would like to have a real Forth system, 
interpreting ascii source.
For flight the number & size of telecommands is limited, therefore it 
would be nice to have bytecodes
with a bytecode compiler/decompiler to be used on ground. That's why I'm 
thinking about FCode.

Thanks & regards,
Rolf.

[Segher Boessenkool]

> For the development phase I would like to have a real Forth system,
> interpreting ascii source.
> For flight the number & size of telecommands is limited, therefore it
> would be nice to have bytecodes
> with a bytecode compiler/decompiler to be used on ground. That's  
> why I'm
> thinking about FCode.

FCode isn't full-featured Forth though, it's more like a
scripting-language subset.  In particular, it doesn't
have DOES> .  FCode isn't much smaller than (compressed)
source text either, btw.

Segher

[Patrick Mauritz]

On 2006-09-19 21:41:53 +0200 Blue Swirl  wrote:
> That can be difficult to achieve, currently the full build is 150k C 
> code + 
> 100k Forth. I don't know how much of the Forth is needed. Taking out 
> unwanted 
> drivers etc. could help a lot on C side, but down to 30-40k?

we were at ~12kb machine code for the C side of the forth system at 
one point. and after that, I think only drivers were added.

patrick mauritz

[Blue Swirl]

> we were at ~12kb machine code for the C side of the forth system at
> one point. and after that, I think only drivers were added.

I did a quick test and disabled the drivers and filesystems, now we are at 
72K:
obj-sparc32/openbios-plain.elf:     file format elf32-sparc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000f578  ffd00000  ffd00000  00004000  2**14
                  CONTENTS, ALLOC, LOAD, CODE
  1 .rodata       0000179c  ffd10000  ffd10000  00014000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000000b0  ffd12000  ffd12000  00016000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0006b000  ffd13000  ffd13000  00017000  2**3
                  ALLOC

Text and rodata can be merged and data segment can be set up manually. The 
interrupt vector table has alignment restriction of 16K which adds a lot of 
NOPs now, but most of that can be saved. So I think we are pretty close to 
64K.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Blue Swirl]

> Does the size of 72 kB include the C runtime library ?

For the OpenBIOS, yes (subset of libc and libgcc). But not for the programs.
> Tomorrow I'll try to manage cross-compilation under cygwin....

In Sparc32/OpenBIOS world, that's going where no man has gone before ;-).

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Stefan Reinauer]

* Rolf Schroedter  [060919 21:16]:
> I'm able to compile & run bare C applications (gcc cross-compiler), so 
> it seems to me that I don't need a real BIOS.

OpenBIOS does not do any bring-up, so it is basically exactly what you
are looking for.

As for the size issues, the 72k include all openfirmware compliance
code, including the device interface, lots of glue code etc pp.
The 6k mentioned here is the forth kernel, without any dictionary, ie.
it is only the "command scheduler" and the primitives.

You might want to look at this old stand-alone version of the openbios
forth kernel: http://www.openbios.org/bin/kernel-1.1.tar.bz2

And plug the fcode evaluator directly on top of that. You can probably
end up with a 32k-48k system (uncompressed).

Hope this helps.

[Rolf Schroedter]

I didn't try the stand-alone kernel-1.1 yet, because it doesn't support 
the sparc-32 architecture.

Seems I managed to cross-compile OpenBIOS on my cygwin for sparc-32, 
removing all file systems & drivers.
Then I'm getting an error dumping the dictionaries:

obj-sparc32/forthstrap -Iforth/bootstrap/ -Iforth/bootstrap/ 
-Iforth/lib/ -Iforth/device/ -Iforth/debugging/ -Iforth/admin/ 
-Iforth/util/ -Iforth/packages/ -Iforth/system/ -Imodules/ -Idrivers/ 
-Iarch/sparc32/ -Iobj-sparc32/forth -D obj-sparc32/openbios-sparc32.dict 
-d obj-sparc32/openbios.dict  arch/sparc32/tree.fs arch/sparc32/init.fs
OpenBIOS bootstrap kernel. (C) 2003-2006 Patrick Mauritz, Stefan Reinauer
This software comes with absolutely no warranty. All rights reserved.

Dumping final dictionary to 'obj-sparc32/openbios-sparc32.dict'
Using source dictionary 'obj-sparc32/openbios.dict'
Compiling dictionary 1/2
 undefined word.
make[1]: *** [obj-sparc32/openbios-sparc32.dict] Error 1
make[1]: Leaving directory 
`/cygdrive/d/Projekt/Bela/prog/test/OpenBIOS/openbios-devel'

Any help is appreciated.
Thanks & regards,
Rolf.

Stefan Reinauer wrote:
> Rolf Schroedter  [060919 21:16]:
> > I'm able to compile & run bare C applications (gcc cross-compiler), so 
> > it seems to me that I don't need a real BIOS.
>
> OpenBIOS does not do any bring-up, so it is basically exactly what you
> are looking for.
>
> As for the size issues, the 72k include all openfirmware compliance
> code, including the device interface, lots of glue code etc pp.
> The 6k mentioned here is the forth kernel, without any dictionary, ie.
> it is only the "command scheduler" and the primitives.
>
> You might want to look at this old stand-alone version of the openbios
> forth kernel: http://www.openbios.org/bin/kernel-1.1.tar.bz2
>
> And plug the fcode evaluator directly on top of that. You can probably
> end up with a 32k-48k system (uncompressed).
>
> Hope this helps.

[Blue Swirl]

> Dumping final dictionary to 'obj-sparc32/openbios-sparc32.dict'
> Using source dictionary 'obj-sparc32/openbios.dict'
> Compiling dictionary 1/2
>  undefined word.

I'd guess a problem with archname or crosscflags scripts. What does uname -m 
return on cygwin?

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Rolf Schroedter]

Blue Swirl wrote:
> > Dumping final dictionary to 'obj-sparc32/openbios-sparc32.dict'
> > Using source dictionary 'obj-sparc32/openbios.dict'
> > Compiling dictionary 1/2
> >  undefined word.
>
> I'd guess a problem with archname or crosscflags scripts. What does 
> uname -m return on cygwin?

openbios-devel $ uname -m
i686

[Rolf Schroedter]

After removing all SBUS stuff from arch/sparc32/tree
'make' finishes without any error.
But no openbios.multiboot is generated, the last built targets file are
obj-sparc32/target/arch/sparc32/{entry.o,vectors.o}

Any hint how to proceed / how should I build my boot image to load to the target ?

Thanks & regards,
Rolf.

[Blue Swirl]

> After removing all SBUS stuff from arch/sparc32/tree
> 'make' finishes without any error.
> But no openbios.multiboot is generated, the last built targets file are
> obj-sparc32/target/arch/sparc32/{entry.o,vectors.o}
>
> Any hint how to proceed / how should I build my boot image to load to the 
> target ?

Compiling for multiboot is not implemented, I don't know if the Sparc boot 
loaders even support the format. Please use openbios-builtin (includes Forth 
dictionary) or openbios-plain.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Rolf Schroedter]

Stefan Reinauer wrote:
> You might want to look at this old stand-alone version of the openbios
> forth kernel: http://www.openbios.org/bin/kernel-1.1.tar.bz2

Okay, I managed to cross-compile kernel-1.1.
(Unfortunately the original kernel-1.1. built process does not support 
cross-platform builts, distinguishing between host and target):
1. Build the kernel & dictionary on my host system (cygwin)
2. Build the target kernel (Leon-Sparc) including the dictionary.h built 
in step 1.

After starting openbios() I'm getting the error:
    panic: dictionary not valid.
load_dictionary() returns -1;

Could this have to do with endianess ? Some other ideas ?
> And plug the fcode evaluator directly on top of that. You can probably
> end up with a 32k-48k system (uncompressed).

The system itself seems to be quite small:
Uncompressed: 26 kB code + 24 kB data
Compressed: 11 kB code + 10 kB data

Thanks & regards,
Rolf.