I'd just like to confirm that I understand what you are proposing correctly.
Given (nonsense) code such as ...
again jmp #again
... are you saying that your assembler will generate either a jmp instruction (1 long) or an FJMP instruction (2 longs) based on wherher you tell it to assemble in LMM mode or not?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Even better... in the case of JMP, if the target is close enough, its smart enough to substitute 'add pc,#offset' or 'sub pc,#offset'
one catch: condition codes won't work on the 2 long version of jump...hmm... they might actually, upper eight bits guaranteed to be clear, should be interpreted by the propeller as a NOP.
Not only does it make life easier for assembly programming... makes compiler writers/porters job easier too
Bill
RossH said...
Hi Bill,
I'd just like to confirm that I understand what you are proposing correctly.
Given (nonsense) code such as ...
again jmp #again
... are you saying that your assembler will generate either a jmp instruction (1 long) or an FJMP instruction (2 longs) based on wherher you tell it to assemble in LMM mode or not?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Sets the "LMM" origin to n, so any code assembled will be in LMM mode, until it hits a
COG
pseudo op. If there is no argument to it, COG sets the cog origin to 0. If there is an argument, it sets the cog origin to that value - with a twist
org 0
cognew #blink,0,1,0 ' pseudo-op to make using coginit easier
... some lmm code ...
blink cog
mov dira,#1
p rdlong r0,#0 'Hz is stored there
add r0,cnt
waitcnt r0
jmp #p
cog $20 ' would move cog origin to $20, AND it would generate the needed 27 longs (zero filled) between $5 and $20 - the skipped area.
.. do more cog stuff
lmm ' switches back to lmm mode, with the correct hub address, each long in the cog section would take one long in the hub
.. do large model stuff ...
cog ' write another cog native routine
... and so on
It is also perfectly valid to place a label on cog statements, so you can refer to their start for cognew 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/12/2009 4:06:45 AM GMT
Am a bit too tired, would make too many mistakes - I've already spent about 11 hours on it today.
I use the forums as a quick break when I need to stop staring at the code.
besides... I'm done implementing (other than a couple of simple pseudo-ops like movk... I'm debugging the code, right now a bit stuck handling an oddball case in my test.asm file... namely, in a cog section, having "word label1, label2" where both are forward references to an lmm section, I am having trouble getting it to resolve correctly, if that has any meaning in such a boundary case.
Bill
RossH said...
@Bill,
An optimising assembler! Sounds great.
So stop wasting your time answering questions on the forum - Go and get on with implementing it
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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 4:10:01 AM GMT
Sets the "LMM" origin to n, so any code assembled will be in LMM mode, until it hits a
COG
Did you mean "LMM n" here? Wouldn't using "ORG n" to set LMM mode break compatibility with PASM? Or do you not plan on keeping such compatibility?
Ross.
I don't think I'll keep 100% compatibility with the propeller tool... it would limit me too much; and while it is easy to generate pure cog code with Las, that is not its reason for being - I don't see anyone using Las to assemble code to be included into a Spin object.
ORG n - sets LMM origin, however, your suggestion has merit - get rid of ORG altogeather, and just use LMM
COG n - sets COG origin, pre-fills with NULL's for the words between 0-n (or previous COG and n)
There are a few other incompatibilities... no CON blocks, use EQU
There is also no need for '@' as every label "knows" if it is in a COG or LMM segment, and its address in the segment its in.
I am considering keeping the '#' notation for LMM code as well, so that for example, JMP label would jump to the address contained in the location pointed to by label, and JMP #label would jump to the label.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Can Yours Assembler generate pure COG binaries that can be placed in EEprom and loaded if it need.
One at time else a few of COG modules at same time and place them in binaries att 2K boundaries
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
it would be easy to generate an image of 16 cogs, but it would still need some code (perhaps in the first cog image?) to do the loading to hub memory afterwards. It would go something like:
$include startup.asm ' the $20 long standard eeprom header
cog ' first cog image
... 1st cog image pasm code here
cog $200 ' pad it out to 2k
cog ' second cog image
... 2nd cog image
cog $200 ' pad it out to 2k
(keep repeating)
cog ' 16th cog image
... pasm code
... this last one could only load the cog up to $1DF, as the original eeprom header takes $20 longs.
Actually Largos already has eeload and eesave commands for saving/loading a 32KB eeprom image to the file system.
Sapieha said...
Hi Bill.
Can Yours Assembler generate pure COG binaries that can be placed in EEprom and loaded if it need.
One at time else a few of COG modules at same time and place them in binaries att 2K boundaries
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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 12:43:14 PM GMT
I have my own loader. What I ned is posiblity to generate COG binary code without any other stuff in it.
In begining I have my info longs in begining of that 2K block but Yours idea at have them in place of special registers was very good.
In that Info I have Driver type/Number, place in Hub of its variables and number of longs to reserve for that driver/Interpreter.
My idea is to generate that COG code + have posiblity to have Constatnts generated in last 16 Longs and that binary block exported to file for loadnig in EEprom in 2K block.
Else even at I can generate more at 1 COG's code at once
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sounds good, and the assembler will support that without any issues.
I plan to use the sixteen last longs as follows:
$1F0-$1F3 - standard Largos mailbox
$1F4-$1FF - setup data for the driver
when the driver was started, par would point at the hub equivalent of $1F0-$1FF (or a copy of them)
Here is how this would be written in Las:
output image
driver0 cog
... pasm code, long's etc
cog $1F0
dmbox0 long 0,0,0,0
dargs0 long 0,0,0,0, 0,0,0,0, 0,0,0,0
driver1 cog
... pasm code, long's etc
cog $1F0
dmbox1 long 0,0,0,0
dargs1 long 0,0,0,0, 0,0,0,0, 0,0,0,0
..................... more drivers ............................
driver15 cog
... pasm code, long's etc
cog $1F0
dmbox15 long 0,0,0,0
dargs15 long 0,0,0,0, 0,0,0,0, 0,0,0,0
end
you can either $include the register definitions you want, or just put them into the file directly. Remember though, no CON section - use EQU like in all other assemblers.
Sapieha said...
Hi Bill.
I have my own loader. What I ned is posiblity to generate COG binary code without any other stuff in it.
In begining I have my info longs in begining of that 2K block but Yours idea at have them in place of special registers was very good.
In that Info I have Driver type/Number, place in Hub of its variables and number of longs to reserve for that driver/Interpreter.
My idea is to generate that COG code + have posiblity to have Constatnts generated in last 16 Longs and that binary block exported to file for loadnig in EEprom in 2K block.
Else even at I can generate more at 1 COG's code at once
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
1.Long .... Driver type number/Interpreter
2.Long .... PAR Adres in HUB
3.Long .... Number X Longs to reserve in HUB for Variables type Buffers.
4.-1FF Long .... Named Variables
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
RossH said...
I wasn't aware that there was a final "standard" set of LMM instructions.
Bill Henning said...
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.
At its root LMM is simply about fetching 'PASM instructions' from Hub and executing them. Any
interpreter doing that has generally been called LMM since the idea was suggested by Bill. XMM
is the equivalent term generally used where the instructions are fetched from off-chip memory.
The mechanisms used for LMM handling of branches, calls and returns ( and anything else that
is added as a 'virtual PASM instruction' ) is a matter of implementation. Bill's notion ( I believe )
was to define what those mechanisms were so independently written LMM-style PASM could be
executed by any other independently written LMM interpreter. This was "Bill's LMM standard",
which is also extensible to add extra 'virtual instructions' as needs arise.
Others ( myself included ) have implemented variants of 'LMM', interpreting PASM instructions
from Hub memory but handling branches, calls and returns etc with a different mechanism to
"Bill's LMM standard".
My opinion is "LMM is the mechanism of fetching then executing from Hub", not about how the
mechanisms for handling branches etc are implemented. I see two standards there; the rdlong
and increment pointer and the rdlong and decrement pointer with LMM interpreted instructions
held in reverse order in memory as per Phil Pilgrim's (PhiPi) suggestion.
Above that, how branches are handled etc, there's "Bill's LMM standard", and other variants
of that and alternative implementations. I tend to see them as "LMM implementations" not as
"LMM" per se. I see it as "LMM" is similar to "Code Overlay"; we all know what it means but
there may be many specific, incompatible, implementations of it. Others may disagree.
We therefore have a terminology issue, as to what "LMM" is and means, and as to what any
"standard" means in relation to that. I don't know how we resolve that or clear up confusion
which arises through there being no clearly defined and universally agreed definition of "LMM".
So, in the absence of a standard we arrive at the situation where Catalina compiled C code will not run on an ICC LLM kernel and vice versa.
My little TINY compiler has its own LMM style and Largos has yet another. How cool would it be if they were a "standard" LMM virtual machine.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's less than an ideal situation, however I agree that people should be able to make their own flavor of LMM.
That's why Largos will allow applications to specify their own flavor of LMM or other interpreter
I will however define a "standard" Largos LMM kernel.
I'm doing regression testing on Las... its taking a bit longer than expected, but I am down to just one code generation issue in COG mode (there are still some missing features, but that is for after UPEW) - it assembles all instructions correctly, including all effect and condition codes, and generates a propeller tool compatible binary file.
heater said...
So, in the absence of a standard we arrive at the situation where Catalina compiled C code will not run on an ICC LLM kernel and vice versa.
My little TINY compiler has its own LMM style and Largos has yet another. How cool would it be if they were a "standard" LMM virtual machine.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
It is fine with standard .... But not in start of Prototyping LMM.
LMM is stil in development and bound it to any standard in that time to is no good idea.
But it is fine to speak about possiblities of that standard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I don't see a problem, if every language has it's own LMM variant. The LMM interpreter code must
anyway be included in the final binary by the compiler.
So every compiler can have an optimized LMM interpreter that fits to the concept of the language
and the special features of the particular compiler.
Las just passed my regression test for cog mode - it built an identical binary to Propeller tool v1.2 for the same (adjusted for CON vs EQU) input file!
A bit more tweaking and I'll put up a 'pre-release' version on my site, either tonite or tomorrow. A couple of days late, but beta late then never!
I'll also post both Las and PT test files, so people can have a basis for test 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
I think Bill's approach is looking very promising. I would love to use Las, since it seems it will very easily be able to do some code optimization that are quite difficult for me to do at the time of code generation. I will also make Catalina comply with a minimum LMM standard (if possible) so that Catalina programs can be executed under Largos - and if that isn't possible (or more correctly, if it isn't possible without sacrificing too much existing functionality) then that probably indicates that the "minimal" standard isn't yet minimal enough, and we all need to work on it some more. That's the good thing about standards - you can just keep changing them!
BTW - it seems likely to me that Catalina will end up with two code generators - one that uses Las, where the executables are intended to run on platforms (probably mostly XMM capable ones) under Largos - and one that uses PASM, where the executables are intended to run on "bare metal" platforms, and where the overhead of Largos is neither necessary nor desirable.
This is a very exciting time to be working on the Propeller. I wish I could be at UPEW to see Bill's work first hand!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Re Hippy's point, about LMM being too generic a term, perhaps Bill should follow the example of the Boehm garbage collector and simply add his name to it: Henning LMM. That way it's clear which particular LMM Bill is talking about, he gets appropriate credit for his work, and it doesn't seem like he's imposing a standard on disparate LMM implementations.
Thanks, and I think you will really like using Las, and while I like the idea of standards, I do not wish to constrain everyone into my idea of what LMM kernels should support. Over time, I've played with several variations myself, although that is extremely painful with the standard Propeller tool, which is why I wrote Las. As Las is capable of generating code for "bare metal" platforms, I don't think that you will really need two code generators - unless you also decide to target Spin bytecodes as different libraries should suffice to account for platform differences.
Largos also supports multiple application images and VM's - the binaries are flagged as to which they require to run in the directory entry.
Thanks, I wish you were coming too! I'd like to meet everyone here (on the forums) someday.
@mpark,
I don't like the name Henning LMM - however I do like the name Largos LMM, and I may do different implementations myself. Ofcourse all LMM's trace their lineage back to my 2006 posting
@all,
The assembler works for basic usage. $include works. byte/word/long/res work for reserving storage and embedding constants and strings. I've verified all the Pasm instructions against Propeller Tool v1.2, by running the same instruction test set through both and comparing the .binary files.
A fair bit of the LMM support works, it is possible to declare LMM sections, it will compile Pasm code into them, CACHE/ENDCACHE blocks generate the correct code and long count, however the LMM side is not thoroughly tested yet. I've had to turn the expression evaluator off due to some multi-legged creatures.
The problem: I have a lot of prep work to do for the Expo. I don't think I can spend much more time on Las for at least a week (if other prep work goes well) or until after the show (of the other prep work does not go well).
Would you guys want to play with a pre-release that does not have all the LMM goodies yet, but works fine as a stand-alone assember? Or should I wait releasing an exe until its more LMM capable?
Even in its current shape it is far easier to use for LMM work than pasm.
What would y'all prefer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Las - Large model assembler for the Propeller (alpha version this weekend) Largos - a feature full nano operating system for the Propeller www.mikronauts.com - a new blog about microcontrollers
"Largos LMM" works for me. And of course anyone who uses any type of LMM should continue to acknowledge your original work.
As for a pre-release of Las - well, I would really prefer not to see it for a few more weeks - precisely because I'd be too tempted to play with it - and I have too many of my own small multi-legged creatures to track down first! But by all means release it if others want it now (and I may just sneak a little peek!).
For the present, I find mpark's Homespun does everything I need by way of a PASM assembler - not having had a tool such as Las available, I tailored my own LMM variant (hereafter to be referred to exclusively as "Catalina LMM") to be compatible with existing PASM compilers - e.g. Catalina LMM binaries are already fully relocatable, since the kernel relocates them "on the fly".
Ross.
P.S. By "bare metal" I meant not using Largos - I fully expected Las to be able to gemerate programs intended to run on bare metal. But even if I don't end up with two separate code generators I may still have a switch to enable/disable Las extensions to PASM. I'm still considering how to have Catalina programs run in conjunction with SPIN programs - ideally, I'd like to see all three (i.e. C/SPIN/PASM) happily coexist. Unfortuanately SPIN is not really geared for this type of thing. But If I could make that work, it would be better if all the PASM was of the same variety (e.g. for debuggers and the like). However, if Las works out well perhaps we could all petition Parallax to adopt it as a replacement for PASM on the Prop II!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Point taken, that having standard to early on (for pretty much anything) is probably not a good idea. If even possible before people have explored all the kinks of the idea.
Still, looks like Catalina and largos are converging. I might take time out to change the noddy TINY compiler to use the same.
This is all fascinating stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've started a new thread for my Las v0.10 "Flying Pigs" release
I got the LMM features in today so I thought people might like to try it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Las - Large model assembler for the Propeller (alpha version released) Largos - a feature full nano operating system for the Propeller www.mikronauts.com - a new blog about microcontrollers
I updated the zip on my site, both exe's are now statically linked, so if you could not run them before, download it again and it should work for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Las - Large model assembler for the Propeller (alpha version released) Largos - a feature full nano operating system for the Propeller www.mikronauts.com - a new blog about microcontrollers
I'd planned on working on drivers today... but after I got up... I just could not resist completing the basic LMM support [noparse]:)[/noparse]
I'll fix the expression evaluator after UPEW.
Bill
RossH said...
@Bill,
Well, there goes my plans for this week I can resist anything except temptation!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Las - Large model assembler for the Propeller (alpha version released) Largos - a feature full nano operating system for the Propeller www.mikronauts.com - a new blog about microcontrollers
Comments
I'd just like to confirm that I understand what you are proposing correctly.
Given (nonsense) code such as ...
... are you saying that your assembler will generate either a jmp instruction (1 long) or an FJMP instruction (2 longs) based on wherher you tell it to assemble in LMM mode or not?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yep, you got it!
Ditto for CALL, RET.
Even better... in the case of JMP, if the target is close enough, its smart enough to substitute 'add pc,#offset' or 'sub pc,#offset'
one catch: condition codes won't work on the 2 long version of jump...hmm... they might actually, upper eight bits guaranteed to be clear, should be interpreted by the propeller as a NOP.
Not only does it make life easier for assembly programming... makes compiler writers/porters job easier too
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
An optimising assembler! Sounds great.
So stop wasting your time answering questions on the forum - Go and get on with implementing it
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
ORG n
Sets the "LMM" origin to n, so any code assembled will be in LMM mode, until it hits a
COG
pseudo op. If there is no argument to it, COG sets the cog origin to 0. If there is an argument, it sets the cog origin to that value - with a twist
org 0 cognew #blink,0,1,0 ' pseudo-op to make using coginit easier ... some lmm code ... blink cog mov dira,#1 p rdlong r0,#0 'Hz is stored there add r0,cnt waitcnt r0 jmp #p cog $20 ' would move cog origin to $20, AND it would generate the needed 27 longs (zero filled) between $5 and $20 - the skipped area. .. do more cog stuff lmm ' switches back to lmm mode, with the correct hub address, each long in the cog section would take one long in the hub .. do large model stuff ... cog ' write another cog native routine ... and so onIt is also perfectly valid to place a label on cog statements, so you can refer to their start for cognew 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/12/2009 4:06:45 AM GMT
Am a bit too tired, would make too many mistakes - I've already spent about 11 hours on it today.
I use the forums as a quick break when I need to stop staring at the code.
besides... I'm done implementing (other than a couple of simple pseudo-ops like movk... I'm debugging the code, right now a bit stuck handling an oddball case in my test.asm file... namely, in a cog section, having "word label1, label2" where both are forward references to an lmm section, I am having trouble getting it to resolve correctly, if that has any meaning in such a boundary case.
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
Post Edited (Bill Henning) : 6/12/2009 4:10:01 AM GMT
Did you mean "LMM n" here? Wouldn't using "ORG n" to set LMM mode break compatibility with PASM? Or do you not plan on keeping such compatibility?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I don't think I'll keep 100% compatibility with the propeller tool... it would limit me too much; and while it is easy to generate pure cog code with Las, that is not its reason for being - I don't see anyone using Las to assemble code to be included into a Spin object.
ORG n - sets LMM origin, however, your suggestion has merit - get rid of ORG altogeather, and just use LMM
COG n - sets COG origin, pre-fills with NULL's for the words between 0-n (or previous COG and n)
There are a few other incompatibilities... no CON blocks, use EQU
There is also no need for '@' as every label "knows" if it is in a COG or LMM segment, and its address in the segment its in.
I am considering keeping the '#' notation for LMM code as well, so that for example, JMP label would jump to the address contained in the location pointed to by label, and JMP #label would jump to the label.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Can Yours Assembler generate pure COG binaries that can be placed in EEprom and loaded if it need.
One at time else a few of COG modules at same time and place them in binaries att 2K boundaries
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
it would be easy to generate an image of 16 cogs, but it would still need some code (perhaps in the first cog image?) to do the loading to hub memory afterwards. It would go something like:
Actually Largos already has eeload and eesave commands for saving/loading a 32KB eeprom image to the file system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 12:43:14 PM GMT
I have my own loader. What I ned is posiblity to generate COG binary code without any other stuff in it.
In begining I have my info longs in begining of that 2K block but Yours idea at have them in place of special registers was very good.
In that Info I have Driver type/Number, place in Hub of its variables and number of longs to reserve for that driver/Interpreter.
My idea is to generate that COG code + have posiblity to have Constatnts generated in last 16 Longs and that binary block exported to file for loadnig in EEprom in 2K block.
Else even at I can generate more at 1 COG's code at once
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Sounds good, and the assembler will support that without any issues.
I plan to use the sixteen last longs as follows:
$1F0-$1F3 - standard Largos mailbox
$1F4-$1FF - setup data for the driver
when the driver was started, par would point at the hub equivalent of $1F0-$1FF (or a copy of them)
Here is how this would be written in Las:
output image driver0 cog ... pasm code, long's etc cog $1F0 dmbox0 long 0,0,0,0 dargs0 long 0,0,0,0, 0,0,0,0, 0,0,0,0 driver1 cog ... pasm code, long's etc cog $1F0 dmbox1 long 0,0,0,0 dargs1 long 0,0,0,0, 0,0,0,0, 0,0,0,0 ..................... more drivers ............................ driver15 cog ... pasm code, long's etc cog $1F0 dmbox15 long 0,0,0,0 dargs15 long 0,0,0,0, 0,0,0,0, 0,0,0,0 endyou can either $include the register definitions you want, or just put them into the file directly. Remember though, no CON section - use EQU like in all other assemblers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Next what I will have.
But my Info will be.
1.Long .... Driver type number/Interpreter
2.Long .... PAR Adres in HUB
3.Long .... Number X Longs to reserve in HUB for Variables type Buffers.
4.-1FF Long .... Named Variables
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
At its root LMM is simply about fetching 'PASM instructions' from Hub and executing them. Any
interpreter doing that has generally been called LMM since the idea was suggested by Bill. XMM
is the equivalent term generally used where the instructions are fetched from off-chip memory.
The mechanisms used for LMM handling of branches, calls and returns ( and anything else that
is added as a 'virtual PASM instruction' ) is a matter of implementation. Bill's notion ( I believe )
was to define what those mechanisms were so independently written LMM-style PASM could be
executed by any other independently written LMM interpreter. This was "Bill's LMM standard",
which is also extensible to add extra 'virtual instructions' as needs arise.
Others ( myself included ) have implemented variants of 'LMM', interpreting PASM instructions
from Hub memory but handling branches, calls and returns etc with a different mechanism to
"Bill's LMM standard".
My opinion is "LMM is the mechanism of fetching then executing from Hub", not about how the
mechanisms for handling branches etc are implemented. I see two standards there; the rdlong
and increment pointer and the rdlong and decrement pointer with LMM interpreted instructions
held in reverse order in memory as per Phil Pilgrim's (PhiPi) suggestion.
Above that, how branches are handled etc, there's "Bill's LMM standard", and other variants
of that and alternative implementations. I tend to see them as "LMM implementations" not as
"LMM" per se. I see it as "LMM" is similar to "Code Overlay"; we all know what it means but
there may be many specific, incompatible, implementations of it. Others may disagree.
We therefore have a terminology issue, as to what "LMM" is and means, and as to what any
"standard" means in relation to that. I don't know how we resolve that or clear up confusion
which arises through there being no clearly defined and universally agreed definition of "LMM".
My little TINY compiler has its own LMM style and Largos has yet another. How cool would it be if they were a "standard" LMM virtual machine.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's why Largos will allow applications to specify their own flavor of LMM or other interpreter
I will however define a "standard" Largos LMM kernel.
I'm doing regression testing on Las... its taking a bit longer than expected, but I am down to just one code generation issue in COG mode (there are still some missing features, but that is for after UPEW) - it assembles all instructions correctly, including all effect and condition codes, and generates a propeller tool compatible binary file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It is fine with standard .... But not in start of Prototyping LMM.
LMM is stil in development and bound it to any standard in that time to is no good idea.
But it is fine to speak about possiblities of that standard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
anyway be included in the final binary by the compiler.
So every compiler can have an optimized LMM interpreter that fits to the concept of the language
and the special features of the particular compiler.
Andy
A bit more tweaking and I'll put up a 'pre-release' version on my site, either tonite or tomorrow. A couple of days late, but beta late then never!
I'll also post both Las and PT test files, so people can have a basis for test 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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I think Bill's approach is looking very promising. I would love to use Las, since it seems it will very easily be able to do some code optimization that are quite difficult for me to do at the time of code generation. I will also make Catalina comply with a minimum LMM standard (if possible) so that Catalina programs can be executed under Largos - and if that isn't possible (or more correctly, if it isn't possible without sacrificing too much existing functionality) then that probably indicates that the "minimal" standard isn't yet minimal enough, and we all need to work on it some more. That's the good thing about standards - you can just keep changing them!
BTW - it seems likely to me that Catalina will end up with two code generators - one that uses Las, where the executables are intended to run on platforms (probably mostly XMM capable ones) under Largos - and one that uses PASM, where the executables are intended to run on "bare metal" platforms, and where the overhead of Largos is neither necessary nor desirable.
This is a very exciting time to be working on the Propeller. I wish I could be at UPEW to see Bill's work first hand!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thanks, and I think you will really like using Las, and while I like the idea of standards, I do not wish to constrain everyone into my idea of what LMM kernels should support. Over time, I've played with several variations myself, although that is extremely painful with the standard Propeller tool, which is why I wrote Las. As Las is capable of generating code for "bare metal" platforms, I don't think that you will really need two code generators - unless you also decide to target Spin bytecodes
Largos also supports multiple application images and VM's - the binaries are flagged as to which they require to run in the directory entry.
Thanks, I wish you were coming too! I'd like to meet everyone here (on the forums) someday.
@mpark,
I don't like the name Henning LMM - however I do like the name Largos LMM, and I may do different implementations myself. Ofcourse all LMM's trace their lineage back to my 2006 posting
@all,
The assembler works for basic usage. $include works. byte/word/long/res work for reserving storage and embedding constants and strings. I've verified all the Pasm instructions against Propeller Tool v1.2, by running the same instruction test set through both and comparing the .binary files.
A fair bit of the LMM support works, it is possible to declare LMM sections, it will compile Pasm code into them, CACHE/ENDCACHE blocks generate the correct code and long count, however the LMM side is not thoroughly tested yet. I've had to turn the expression evaluator off due to some multi-legged creatures.
The problem: I have a lot of prep work to do for the Expo. I don't think I can spend much more time on Las for at least a week (if other prep work goes well) or until after the show (of the other prep work does not go well).
Would you guys want to play with a pre-release that does not have all the LMM goodies yet, but works fine as a stand-alone assember? Or should I wait releasing an exe until its more LMM capable?
Even in its current shape it is far easier to use for LMM work than pasm.
What would y'all prefer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this weekend)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
"Largos LMM" works for me. And of course anyone who uses any type of LMM should continue to acknowledge your original work.
As for a pre-release of Las - well, I would really prefer not to see it for a few more weeks - precisely because I'd be too tempted to play with it - and I have too many of my own small multi-legged creatures to track down first! But by all means release it if others want it now (and I may just sneak a little peek!).
For the present, I find mpark's Homespun does everything I need by way of a PASM assembler - not having had a tool such as Las available, I tailored my own LMM variant (hereafter to be referred to exclusively as "Catalina LMM") to be compatible with existing PASM compilers - e.g. Catalina LMM binaries are already fully relocatable, since the kernel relocates them "on the fly".
Ross.
P.S. By "bare metal" I meant not using Largos - I fully expected Las to be able to gemerate programs intended to run on bare metal. But even if I don't end up with two separate code generators I may still have a switch to enable/disable Las extensions to PASM. I'm still considering how to have Catalina programs run in conjunction with SPIN programs - ideally, I'd like to see all three (i.e. C/SPIN/PASM) happily coexist. Unfortuanately SPIN is not really geared for this type of thing. But If I could make that work, it would be better if all the PASM was of the same variety (e.g. for debuggers and the like). However, if Las works out well perhaps we could all petition Parallax to adopt it as a replacement for PASM on the Prop II!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Still, looks like Catalina and largos are converging. I might take time out to change the noddy TINY compiler to use the same.
This is all fascinating stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I got the LMM features in today
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version released)
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 released)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Well, there goes my plans for this week
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'd planned on working on drivers today... but after I got up... I just could not resist completing the basic LMM support [noparse]:)[/noparse]
I'll fix the expression evaluator after UPEW.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version released)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
If it's not Parallax then don't even bother. :-)
Propeller SRAM TV driver winner: ==NOT COMPLEATED:·1·WEEK UNTIL ENDING TIME==