Largos update, Las information (large model OS, assembler)
Bill Henning
Posts: 6,445
Hi,
I've started the documentation pages for both Largos (my LMM based OS for the Propeller) and Las (my LMM assembler for Largos) at my site; links in my sig.
For now I posted
- the initial Largos feature set, and a simple performance benchmark result for message passing (almost 2300 empty messages processed per second by the prototype Spin kernel)
- the initial Las feature set, definition of Las pseudo ops, and "coming soon" features for it.
I am taking comments and suggestions for the posted information on both Largos and Las, either here, or on my site (you have to register to post, I do this to avoid spam)
I will mostly post Largos and Las updates to my site as I don't want to clutter this forum.
Now back to working on Las and Largos...
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
I've started the documentation pages for both Largos (my LMM based OS for the Propeller) and Las (my LMM assembler for Largos) at my site; links in my sig.
For now I posted
- the initial Largos feature set, and a simple performance benchmark result for message passing (almost 2300 empty messages processed per second by the prototype Spin kernel)
- the initial Las feature set, definition of Las pseudo ops, and "coming soon" features for it.
I am taking comments and suggestions for the posted information on both Largos and Las, either here, or on my site (you have to register to post, I do this to avoid spam)
I will mostly post Largos and Las updates to my site as I don't want to clutter this forum.
Now back to working on Las and Largos...
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Comments
You also mentioned loading spin applications. Will they have access to the standard os libraries for using i/o and stuff?
Please note I intend to get Las running on my Mac and my Ubuntu box as well.
Spin applications running under Largos will have to be slightly modified. They will have to:
- include the "os" object to get access to all of the OS capabilities (for I/O, file system, loading drivers, etc)
- they should not set _clkmode and _xinfreq, the OS does that - they can read them from the hub
- they should not include drivers available in the OS, but use the OS services
If the app obeys the rules above, it should just be a matter of compiling them to a .binary file, as Largos will load .binary files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Sounds like a great project! Does each driver/service that gets loaded into the OS run in a separate cog? I would imagine that you would also have to take into consideration how many driver/services would be 'in memory' when your code was running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
I was hoping someone would do a 'UNIX"ish OS. I have been a unix geek for 20 years and the commands roll off my fingers.
What are the hardware requirements?
Is there a download link, or is this just a preteaser?
Thanks,
Doug
Post Edited (hinv) : 6/10/2009 12:29:29 AM GMT
There is some more info on both Largos and Las on my blog, I'll keep updating those pages with progress reports. I hope to demo both at UPEW - rather, I WILL demo both, in whatever shape they are in by that time
Largos is quite Unix-y on the surface, here are some of the (implemented) shell commands that already work (in the monolithic shell version, I have to still rip it apart and make it into a real Largos client):
cat cd du df ls rm rmdir mv mkdir mkfs pwd touch (additional commands coming soon)
here are the currently working stdio calls:
putc getc puts gets getline (with backspace support)
the file system calls are close to the Unix ones as well.
I think people will like it
It's looking like the initial version will have about a 10KB hub footprint, however that includes 2KB for a buffer for loading kernels, drivers, etc - and as I re-write it in Las, I expect the footprint to drop to around 8KB. Large spin programs that use many drivers will actually have more free memory under Largos, as it loads the drivers directly from flash, so they are not resident in the hub after they are started up.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Most drivers will run as a separate cog, but some are shared - there is a combined keyboard/mouse driver I intend to port to Largos, and there is the quad serial. I am also thinking about combining my SPI and I2C drivers into one cog. Drivers/services don't have a footprint in the hub after being loaded - other than a 16 byte mailbox
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Thanks for supporting binaries.. It'll allow me to make a easy move from
PropDOS to Largos without recompiling everything. Very nice..
Edit: re-read your description.. Any chance of getting support for
kickstarting "incompatible" binaries? [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Post Edited (Oldbitcollector) : 6/10/2009 4:32:01 AM GMT
They will run, but there may not be enough free cogs for all apps - currently the prototype needs at least two cogs to run in order to provide kernel and file system services.
It should be noted that it will be very easy to configure Largos - just edit /etc/rc.local and /etc/modules
Give me a month or so and I'll have Largos down to one cog for minimal setups (ie just basic kernel + file system, possibly even bit-banged serial console in the same cog), then as long as a standard Spin app does not touch my SPI flash pins, it will run as-is. Until I have time to do an SD version of my file system Largos will require a Winbond 25X80 or compatible SPI flash for its root file system.
Before anyone asks... Largos will never use any form of FAT for its root file system as it is not appropriate for a Unix like OS. I will however provide at the very least some commands to copy to/from FAT formatted SD cards - I am going to call them "mdir", "mcd", "mread" and "mwrite" - shades of old Linux utilities
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/10/2009 5:24:34 AM GMT
/etc/rc.local ? /etc/modules ?
I don't think "Largos" is an appropriate name anymore - I vote for BILLIX!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
How do you start a cog task without fork? clone maybe?
Do you have room for KLMs and standard driver APIs (open,close,ioctl,read,write)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Here, laugh some more - here is the directory tree on my Winbond:
/bin
/dev
/etc
/etc/modules
/etc/rc.local
/lib
/home
/roms
/usr
/usr/bin
/usr/man
/usr/src
/var
/var/log
/var/log/messages
Does any of that look a teeny bit familiar? Ofcourse /etc/modules, /etc/rc.local, /var/log/messages are just text files, not directories.
/roms is where full eeprom images get stored for ported eeprom games, femto basic once pin-adjusted, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/10/2009 5:45:24 PM GMT
spawn() - starts a new task in a new cog, LMM/Spin/otherVM based on args
exec() - replaces the shell for BIG apps, can be used to do things like chaining multi pass compiers for example.
Any newly started process can be used to extend the kernel, special sauce will be revealed later
Standard driver API's? What are those?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/10/2009 5:46:49 PM GMT
Common Bill, lettuce have the special sauce [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
No, not yet... I won't have time until after the Expo. It's based on message passing, and actually C will be more efficient at sending the messages than Spin.
You will like the fact that I support launching arbitrary different LMM kernel versions based on file type. I'm in the middle of finalizing the relocatable file format, I am leaning towards removing having separate code and data segments and just having one relocation chain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/10/2009 8:47:12 PM GMT
I'm leaving the special sauce for later...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/10/2009 8:52:28 PM GMT
Can't wait to get my hands on it.
Now I just have to find one of those winbond chips in auz...
Worst case, you can order the Winbonds from Digikey - however pretty much any SPI flash that has 4KB erasable sectors should work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
The relocation file not needed in IMAGE mode where it generates an absolute eeprom image, but it is definitely needed when generating LMM apps.
I decided to use a simple text file format for the relocation information, each record is on its own line, encoded as: "%C%06X\n" - a single character 'L' or 'W' for LONG or SHORT destination followed by a six hex digit offset into the OBJ file, which implies that the largest supported LMM executable size is 16MB (for now).
I was going to use a binary file, but decided that for debugging purposes, wasting a bit of disk space was well worth it for a human-readable relocation file.
I am now in the process of squishing a bug with forward referencing... then a bit more LMM support and its ready for outside testing!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/11/2009 1:22:15 PM GMT
Would you guys like it if the assembler auto-magically did the translations for multi-long LMM equivalents for the following COG instructions:
JMP #label
CALL #label
RET
DJNZ reg,#label
(maybe more later)
It would get rid of having to remember to use FJUMP, FCALL, FRET, and would add a source level equivalent to DJNZ.
I would even add a bit of automatic optimization - if the label was in range, then JMP and DJNZ would use add/sub pc,#offset instead of a long with the destination address.
JMPRET makes no sense in the LMM context as CALL/RET will use a stack for return addresses
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Las will standardize "core" LMM programming, however I believe that a lot of people will still extend the LMM kernel with features I did not add - my theory was "KISS".
Las is practically usable right now, I am just finishing some tricky issues like forward referencing labels in long's declared in COG or FCACHE or LMM sections... they need to be fixed up differently depending of the mode of the code and the mode of the label when it is defined. After thats working, I'll add the automagic LMM support I discussed above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Yes, I think it would be great for LMM to automatically calculate the jmp/call/ret instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I wasn't aware that there was a final "standard" set of LMM instructions. I was of course aware of your brilliant original proposal for LMM here, but the last post on that thread was in 2007. Is that what you're referring to? As far as I can see there are only about half a dozen LMM instructions defined there (next/call/ret/cache/etc). I know there's a lot of more recent information on LMM in various other forum threads, but finding all the relevent stuff with the braindead forum search function (or even using the Google plugin) is so difficult that I wouldn't really be surprised that something like a fully fleshed out LMM standard could exist without my knowing about it. I actually got a lot of my LMM information from the Propeller Wiki (here) which is much easier to use. However, it describes a couple of different LMM implementations, and it also seemed a bit out of date compared to current developments so I ended up mostly creating my own (which I acknowledge is not well documented, so you've at least prompted me to put my own house in order and get on with that little job!).
However, the point of this post is that I'm just not sure there even should be such a thing as "standard" LMM. While writing Catalina I found the need to include a significant number of LMM primitives - far more than allowed for in the original proposals - to improve kernel support for a general purpose stack and frame based language. There were also several of the proposed LMM primitives (such as cache) that I just found too difficult to use effectively, and which wasted too much space in the kernel that I wanted to use for other things. Of course, before richard (Imagecraft) chimes in here, I'm aware that ICCPROP does use caching, and doesn't (as far as I know) add any new kernel primitves of its own, so my inability to use your original LMM propsal efficiently probably says more about my lack of compiler writing ability than it does about anything else - but this is beside the point I am trying to make, which is ....
I don't think of LMM as a static thing with a defined set of primitives. Forget about caching - even having call/ret as primitives presupposes a particular overlying architecture (i.e. stack based). For me, LMM is a technique, not a solution - and having the ability to redefine LMM primitives in order to meet the needs of the job in hand is one of the great things about the original concept (kudos to you!) and also about the ability of the Prop to bring it off (kudos to Chip Gracey and the Parallax team!). I've just gone back to re-read at your original LMM proposal, and (without trying to detract from it at all), the reasons I departed from it are still valid. They were necessary to better accomodate my original design goals for Catalina - e.g. Catalina required better frame support, plus more new LMM primitives than were originally allowed for, plus more general purpose registers than were originally allowed for.
I think your LMM assembler has to accomodate many variants of LMM. If you can make it so that your assembler allows you to define a particular machine architecture (typically, just a set of registers) plus a customizable set of LMM primitives then I think you will have a great solution.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
@RossH - ah... slight misunderstanding, we are far more on the same page as you think.
There was not supposed to be a "final standard" that defined THE LMM kernel that none may modify - that was not the idea.
The idea was that there is supposed to be a "standard minimum subset" that everyone has to support - with everyone free to add extensions.
I am a big believer in the KISS principle, so the initial proposal deliberately limited the new instructions in order to leave as much kernel cog space free as possible, specifically so people could do useful extensions (like direct support for stack frames with variables on the stack, direct floating point support etc). I know that FCACHE is something that requires a fair bit of chewing on to use effectively, but I will in the future write an app note or two on it.
Now that my assembler is running (I still have some bugs to squash (forward referencing from a word embedded in a long in a cog section) before making a public pre-release of it) everyone will see how I will be using it.
I am making my assembler be extremely generic, so that it will work well for any kind of LMM kernel!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Ok - thanks. I though that perhaps there was a standard somewhere that I had missed.
Keep up the good work!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The biggest problem I faced when learning the LMM primitives was "what the heck does that mean and why are there 2 longs after that statement".
Simplifying the minimum primitives to "one line instructions" as Bill had in his post along with a full explanation of what the primitives mean would help new users tremendously.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Documentation will be forthcoming... but less will be needed once my assember is out - because I've decided to hide most of the differences.
There will no longer be a need to know the difference between JMP / FJMP, CALL / FCALL, RET / FRET - the assembler will generate the correct code depending on the mode it is in when it encounters the line with the opcode in it.
FCACHE stays, although I may rename it CACHE... and the block is now ended with ENDCACHE - the assembler computes (and places into the right place) the number of longs to load.
It is delaying the assembler a few days, but I am making LMM be FAR more transparent and easier to use for everyone, so I believe the delay is worth it.
Here is one of the future example programs that will come with Las:
output image org 0 $include startup.asm ' the $20 byte header that runs cognews the code at $20 $include lmmkernel ' 512 long kernel, that starts up LMM code at $220 mov dira,#1 again xor outa,#1 movk r0,#80000000 ' new pseudo-op, loads a 32 bit constant into any cog register add r0,cnt waitcnt r0 jmp #again endmovk will take the constant from the long following the CALL FMOVK, where FMOVK is a new kernel function.
ofcourse the "output/org/two includes" could be replaced with a single "$include kimage.asm", and the end is optional
$include kimage.asm mov dira,#1 again xor outa,#1 movk r0,#80000000 ' new pseudo-op, loads a 32 bit constant into any cog register add r0,cnt waitcnt r0 jmp #againIs that simple enough for a stand-alonge eeprom image lmm program that blinks P0?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 6/12/2009 3:36:24 AM GMT