I've been too busy with consulting work to update it recently - but I will start updating again next week.
Here is a sneak peek at some of the changes:
HUB MEMORY:
0000-000F Initialization area, I'd leave it as defined (I hope to eventually run Spin programs under this scheme)
0010-00FF Reserved for OS mail boxes, pointers to library bases, etc
0100-01FF 32 mailboxes of eight bytes each
0200-03FF I/O buffer 0 - 512 bytes
0400-0BFF I/O buffers 1..4, also used loading area for cog kernel images
0C00-77FF available memory, managed by primitives imaginatively called 'malloc' & 'free' or 'kmalloc' and 'kfree'
7800-7BFF process control blocks
7C00-7FFF system library
(on the next propeller with 128k the PCB's and system library move to the end of ram, and I'll be greedy and double their size)
The system library implements:
- block SD driver, simple read/write/erase 512 byte blocks, NO FS layer support here
- I2C eeprom support on the default pins, simple read/write/erase 512 byte blocks
- serial I/O over the default pins, simple setbaud (just saves it in a hub location)/read/write
- SPAWN, KILL, MALLOC and FREE
- minimal string library (strcpy, strcmp, atoi, itoa)
- minimal memory library (memcpy, memcmp, memset)
- minimal 32 bit IEEE floating point library (FADD, FSUB, FMUL, FDIV, FREM, FTOI, ITOF, and if it fits, FSIN, FCOS, FTAN, FLOGN, FEXP, FTOA, ATOF)
(I realize that I am very optimistic as to how much can be sqeezed into the 1KB system library area; its size may have to be increased, or the floating point library could be dropped from being part of the base system library)
The mailboxes are for message passing; processes will communicate via simple messages.
The SPAWN routine loads 2KB (512 longs) into IO buffers 1..4 and then COGNEW's it. In order to simplify code (and thus keep it small), SPAWN can only load from block (512 byte) aligned starting locations from either I2C or SD card, and without any file system - just a starting block offset.
KILL can just kill a thread or stop a whole cog.
MALLOC and FREE are obvious; each block of memory has two word pointers at the front of it. The first one points to the next block, and the second poits to the process table entry that owns it. When FREEing a block, adjacent free blocks will automatically be merged (thus hopefully cutting down on fragmentation and avoiding the need for periodic garbage collection)
Every process will also get an STDIN and STDOUT handle however I am thinking of all processes sharing a single STDERR in order to save memory. I/O handles are just pointers to a mailbox; messages equivalent to open/read/write/ioctl/close will be defined.
The whole system will have an extremely minimalist Unix-like feel, however the intention is to make it a 'nano' sized system - I think micro kernels are too large.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 3/4/2007 5:07:38 PM GMT
Bill, did you mention how DCACHE will be used? If it's for caching HUB memory locations, how do you propose to modify the rd/wr HUB instructions to use the faster DCACHE?
DCACHE is meant to be used as a data cache; for things like string operations, reading/writing blocks for devices etc under program control; however you are correct, a smart loader could use the dcache area to hold global longs, and patch the RDLONG/WRLONG's in the hub to instead refer to registers in the DCACHE area.
I was also considering a paged array model, where the dcache could be used to hold two 64 element blocks.
FYI, I have a running kernel, finally had time to debug it and I did change FCACHE a bit.
OLD WAY, OBSOLETE:
FCACHE
<many longs of code, 0 not a valid long>
0 ' indicates end of block
NEW, CORRECT WAY:
FCACHE
number of longs to load
<longs to load>
Please note that if the fcached block is smaller than 128 longs, after the code you can have pre-initialized variables!
How's the assembler & compiler coming?
p.s.
It was EXTREMELY painful to write large model test code in the spin environment... the test program is very...icky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
BTW, to resurrect this thread (ha ha), let me put on public record that the ImageCraft C will use at the minimum some ideas from Bill Henning's LMM with contributions from Mike Green, Chip etc. We *will* fully document the runtime architecture: register maps, COG RAM usage, entry points etc. At this moment, our LMM will look a bit different from Bill's proposal, mainly in terms of lack of support for the threading, the number of registers and the COG RAM usage. There will also be different kernel routines, to support C. Also, experience has shown that most C loops are not that bad, so the FCACHE will probably be smaller, to give more space to the internal stack.
Anyway, I'd like to thank and acknowledge Bill Henning publicly for the LMM idea. It's reasonably obvious once someone discovers it, but certainly without such mechanism, Propeller C would not of much use.
I want in, this is cool! I think I'd like to write a shell for the new system once it's finalized.. I need to learn the instruction set for the Prop's ASM, but I'll need to do that anyway for my next project.
I would like to suggest a trap and interrupt system. I know that with the other Cogs such a system isn't strictly needed, but it would be very interesting to see the kernel pass along the interrupts to the client programs -- perhaps that is part of what the mail box is for? With all the different applications of the chip what causes interrupts and what doesn't would be hard to figure out.
Comments
I've been too busy with consulting work to update it recently - but I will start updating again next week.
Here is a sneak peek at some of the changes:
HUB MEMORY:
0000-000F Initialization area, I'd leave it as defined (I hope to eventually run Spin programs under this scheme)
0010-00FF Reserved for OS mail boxes, pointers to library bases, etc
0100-01FF 32 mailboxes of eight bytes each
0200-03FF I/O buffer 0 - 512 bytes
0400-0BFF I/O buffers 1..4, also used loading area for cog kernel images
0C00-77FF available memory, managed by primitives imaginatively called 'malloc' & 'free' or 'kmalloc' and 'kfree'
7800-7BFF process control blocks
7C00-7FFF system library
(on the next propeller with 128k the PCB's and system library move to the end of ram, and I'll be greedy and double their size)
The system library implements:
- block SD driver, simple read/write/erase 512 byte blocks, NO FS layer support here
- I2C eeprom support on the default pins, simple read/write/erase 512 byte blocks
- serial I/O over the default pins, simple setbaud (just saves it in a hub location)/read/write
- SPAWN, KILL, MALLOC and FREE
- minimal string library (strcpy, strcmp, atoi, itoa)
- minimal memory library (memcpy, memcmp, memset)
- minimal 32 bit IEEE floating point library (FADD, FSUB, FMUL, FDIV, FREM, FTOI, ITOF, and if it fits, FSIN, FCOS, FTAN, FLOGN, FEXP, FTOA, ATOF)
(I realize that I am very optimistic as to how much can be sqeezed into the 1KB system library area; its size may have to be increased, or the floating point library could be dropped from being part of the base system library)
The mailboxes are for message passing; processes will communicate via simple messages.
The SPAWN routine loads 2KB (512 longs) into IO buffers 1..4 and then COGNEW's it. In order to simplify code (and thus keep it small), SPAWN can only load from block (512 byte) aligned starting locations from either I2C or SD card, and without any file system - just a starting block offset.
KILL can just kill a thread or stop a whole cog.
MALLOC and FREE are obvious; each block of memory has two word pointers at the front of it. The first one points to the next block, and the second poits to the process table entry that owns it. When FREEing a block, adjacent free blocks will automatically be merged (thus hopefully cutting down on fragmentation and avoiding the need for periodic garbage collection)
Every process will also get an STDIN and STDOUT handle however I am thinking of all processes sharing a single STDERR in order to save memory. I/O handles are just pointers to a mailbox; messages equivalent to open/read/write/ioctl/close will be defined.
The whole system will have an extremely minimalist Unix-like feel, however the intention is to make it a 'nano' sized system - I think micro kernels are too large.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 3/4/2007 5:07:38 PM GMT
Bill, did you mention how DCACHE will be used? If it's for caching HUB memory locations, how do you propose to modify the rd/wr HUB instructions to use the faster DCACHE?
I was also considering a paged array model, where the dcache could be used to hold two 64 element blocks.
FYI, I have a running kernel, finally had time to debug it
OLD WAY, OBSOLETE:
FCACHE
<many longs of code, 0 not a valid long>
0 ' indicates end of block
NEW, CORRECT WAY:
FCACHE
number of longs to load
<longs to load>
Please note that if the fcached block is smaller than 128 longs, after the code you can have pre-initialized variables!
How's the assembler & compiler coming?
p.s.
It was EXTREMELY painful to write large model test code in the spin environment... the test program is very...icky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Anyway, I'd like to thank and acknowledge Bill Henning publicly for the LMM idea. It's reasonably obvious once someone discovers it, but certainly without such mechanism, Propeller C would not of much use.
Now all we have to do is to finish the compiler
The very best ideas usually are.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
I would like to suggest a trap and interrupt system. I know that with the other Cogs such a system isn't strictly needed, but it would be very interesting to see the kernel pass along the interrupts to the client programs -- perhaps that is part of what the mail box is for? With all the different applications of the chip what causes interrupts and what doesn't would be hard to figure out.
especially for people like me - new to propeller
workin through the forum and then - dead end
looks like there is a whole lot of activity in 2006/2007 and then ... end ...
any results from this great work here?
products that build on this?
further reading?
links?
thanks - a very enthusiastic propeller newbie
MJB
http://forums.parallax.com/forumdisplay.php?91-Propeller-GCC-Alpha-Test-Forum
Bill Henning may have single handedly shaped the future of Propeller programming!
Prop1 C codes like Catalina, GCC, and the other one all make use of it to allow programs of virtually unlimited size and also run faster than SPIN.
Prop2 is going to rely very heavily on this mode as probably a greater number of people will be using C with it...
Thanks Bill for your efforts...
Bean