preliminary (WORKING) Large Model Kernel - and dumb test program

Bill Henning

Hi guys,

Here is a (mostly) working Large Model Kernel, with a really pathetic test program. Spin is NOT well suited to writing LMM code!

fjump, fcall, fret, fcache, fyield have been tested

New, untested extensions for better compiler support:

fldi - load immediate into R0
fpushi - push immediate onto the stack
fpush - push R0 onto the stack
fpop - pop top of stack into R0
fhalt - halt the kernel on the current cog

unimplemented & reserved

fsvc - future use - call OS service routine
flib - future use - call shared library

I welcome your questions & suggestions!

---
v0.51 - fixes fcache bug & extra pc+4 in start method that Mike pointed out - thanks Mike!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Post Edited (Bill Henning) : 11/30/2007 6:57:26 AM GMT

Mike Green

1) Where does rdl get reinitialized?

2) In the kernel start, you set the pc to addr+4. Why? You already increment the pc
by 4 in the initialize routine. It would make more sense to just pass the actual initial
pc rather than providing in the initialization routine for a single long parameter for some
purpose. You could always access the parameter(s) at negative offsets from the initial pc
or at positive offsets from the start of the memory block (which so far isn't used).

Bill Henning

Hi Mike,

1) good catch, an edit killed it - rdl gets re-initialized before jmp #next_op

'****************************************************************************************
' FCACHEX     cache code from hub memory into cog, then execute it
'****************************************************************************************

fcachex       rdlong    tmp,pc

fcloop        add       pc,#4
rdl           rdlong    $80,pc
              add       rdl,destincr
              djnz      tmp,#fcloop
              movd      rdl,#80
              jmp       #icache                 ' end fcache'd code with jmp 1

2) I was thinking of prefixing each large model program by an long, which would be the number of longs in that memory block; sp could then be computed, which would help with the multi-threaded kernel; however I can serve the same purpose by fetching that long from a negative offset as you suggest, so I can kill that add pc,#4

Mike Green said...
1) Where does rdl get reinitialized?

2) In the kernel start, you set the pc to addr+4. Why? You already increment the pc
by 4 in the initialize routine. It would make more sense to just pass the actual initial
pc rather than providing in the initialization routine for a single long parameter for some
purpose. You could always access the parameter(s) at negative offsets from the initial pc
or at positive offsets from the start of the memory block (which so far isn't used).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Mike Green

Don't forget that you're also incrementing by 4 in the start routine. You need to take that out.

For documentation purposes, you should use "icache" instead of "$80" in FCACHEX.

Post Edited (Mike Green) : 11/30/2007 6:36:40 AM GMT

Bill Henning

Done

Mike Green said...
Don't forget that you're also incrementing by 4 in the start routine. You need to take that out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Mike Green

Just something to think about ... Currently your start routine takes the initial pc value as the start of the memory block and computes the initial stack pointer from the start of the memory block and the block size (putting the stack at the end). This is usually what is wanted, but I can imagine some circumstances where you would want to specify these three pieces of information separately. In particular, where the code is shared and there are multiple stacks, whether because you're executing the code on multiple cogs or in multiple threads with the same cog, you'd want separate stack areas and it becomes messy and error prone to have to fudge the block size just to say where the stack starts.

Bill Henning

Good point... probably the most flexible way of handling it is within the start routine.

I'm also starting to give some thought to an overlay manager; my initial inclination is to keep it simple and just essentially "chain" replacing all of the code, but keeping the stack and global variables - but it may be worthwhile to have a a slightly more sophisticated approach that would allow for some shared code (perhaps application specific common functions) and chaining just modules after the common code.

Mike Green said...
Just something to think about ... Currently your start routine takes the initial pc value as the start of the memory block and computes the initial stack pointer from the start of the memory block and the block size (putting the stack at the end). This is usually what is wanted, but I can imagine some circumstances where you would want to specify these three pieces of information separately. In particular, where the code is shared and there are multiple stacks, whether because you're executing the code on multiple cogs or in multiple threads with the same cog, you'd want separate stack areas and it becomes messy and error prone to have to fudge the block size just to say where the stack starts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Post Edited (Bill Henning) : 11/30/2007 6:53:13 AM GMT

Mike Green

Bill,
There's something screwy going on with your editing process. In the version you just corrected, there's a blank line where you should be initializing k_pc in the start routine. Also, you have to change your demo program so the initial pc points to the first instruction (@code+4).

Bill Henning

Ooops. I am adding back the k_pc initialization, but the kernel will add the four in the initialization code for now.

I uploaded the code tonight because Ale needed a kernel to test against; normally I would have waited until I had a better demo

Mike Green said...
Bill,
There's something screwy going on with your editing process. In the version you just corrected, there's a blank line where you should be initializing k_pc in the start routine. Also, you have to change your demo program so the initial pc points to the first instruction (@code+4).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Post Edited (Bill Henning) : 11/30/2007 7:00:12 AM GMT

Ale

Thanks Bill, I'll now do the preprocessor with a configuration file, so more/other kernel primitives can be easily added/modified (you have chosen other names for instance and some other way of calling/etc), without recompiling.

I have to make a description of how everything fits together with this model having a look at yours to see if merging our ideas can give a better kernel

I do no have experience with old systems (from the 60s and 70s) but this looks quite alike in some ways.

ok. I read your code, I'll explain my ideas shortly. This is exciting !

Bill Henning

Hi Ale,

I used my old convention - the one I designed when I came up with the large memory model over a year ago you might want to read that original thread as it explains my kernel.

I only took a quick peek at what you've done - will take a longer look when time permits - my philosophy is to have a VERY minimal kernel, using only $90 (142) longs of cog memory.

Ale said...
Thanks Bill, I'll now do the preprocessor with a configuration file, so more/other kernel primitives can be easily added/modified (you have chosen other names for instance and some other way of calling/etc), without recompiling.

I have to make a description of how everything fits together with this model having a look at yours to see if merging our ideas can give a better kernel

I do no have experience with old systems (from the 60s and 70s) but this looks quite alike in some ways.

ok. I read your code, I'll explain my ideas shortly. This is exciting !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers