Another Propeller Assembler

hippy

Here's a sneak preview of a Windows-based Propeller Assembler I'm currently working on, part of a larger project to compile Spin bytecode and ultimately Spin itself.

Ale

Hippy, that is quite impressive list of features ! I will have to hurry up with mine assembler, so It does not look so primitive , Good Work !

So did you implement ORG correctly (i.e. like in every other assembler...) ? I think so.
What about res ?, do you allow more code after res or not ?, I missed that one. ( Iwanted to replace it with a long 0, to allow more code afterward, or maybe warn...)

The value changing variables are very helpful to repeat a block of code (like repeat in tasm and maybe masm).

On another note, we should get some consensus about how to implement some large memory model, and embed it into the assembler, that would give a boost to speed in general... what do you think ?

Post Edited (Ale) : 8/22/2007 5:38:10 AM GMT

deSilva

Looks extremely well!

@Ale: There can never be anything after RES except you implement an intelligent relocating loader!
The same problem exists wrt ORG.
What you can do with ORG however is checking for overlay (forbidden!) and padding if a gap is required. Padding RES cells makes not much sense, I think.

hippy

Ale said...
So did you implement ORG correctly (i.e. like in every other assembler...) ? I think so.

Only be accident, and incorrectly. It's been quite hard to get my head around the concept that a .eeprom image isn't the same as a Rom/Flash image a traditional single CPU processor would have.

This is definitely a case where a picture ( or two ) would be worth a thousand words.

Ale said...
What about res ?, do you allow more code after res or not ?, I missed that one. ( Iwanted to replace it with a long 0, to allow more code afterward, or maybe warn...)

deSilva said...
@Ale: There can never be anything after RES except you implement an intelligent relocating loader!

I had completely misunderstood the significance and under-estimated the importance of RES until I read the deSilva Machine Language Tutorial again - many thanks for that effort. I've implemented RES wrongly at present, being fixed as I write.

Ale said...
On another note, we should get some consensus about how to implement some large memory model, and embed it into the assembler, that would give a boost to speed in general... what do you think ?

I agree, but I'm going ahead without concensus for now to see where I can get to. Large Memory Model is important to me and I am trying to make it easy to use. The "OVERLAY <size>" is currently used to specify an 'overlay other pages into here' area and "ORG OVERLAY" is used to create pages to overlay with their ORG and sizes set to match with the earlier OVERLAY area.

I aim to add some 'macro opcodes' to handle the Large Memory Model just as if they were any other native Propeller opcodes. These would automatically set themselves however a micro-kernel had been specified for doing the paging/overlaying. I want to keep it generic so everyone is free to implement micro-kernels and Large memory Models however they want ( the basic concept will be the same, but practicalities may differ ). I want to let people produce 'reference designs' but not tie anyone to only reference designs.

I want it to ultimately be so the programmer can write their code as if each Cog had 8K longs of linear memory with only minimal effort and 'code decoration' needed to make that work. I've got some reading, thinking, design and proofing of concept to do before that becomes a reality

Ale

Hippy,

did you program in asm for the x86 ?, I mean, in real mode.... or did you have a look at the compiled code of a Turbo Pascal executable ?, they seemed to use something like one segment per two or three functions, or maybe one per unit. Very bizarre at first thought... interesting, especially the relocations scheme.


May be we should implement some "call into overlayed function", and the compiler generates a call to the kernel, overlay is loaded and the "ret" is again taken by the kernel... (that sound nice... !), but overlayed routines would not call other overlayed routines, unless the overlay space is somehow reduced to 2 pages or so... that would be possible... remember there is no stack...

More or less as they do it in the TI-8x (not 89) calculators...

I am drafting some implementation, around the lines I mentioned, I'll post them when ready.

Have fun

ALe

hippy

@ Ale : Not really familiar with x86 or how others have done overlays, so just I busked it as how I though it would best work for me. This is definitely a 'load a page, execute it' overlay scheme than anything else. I'll go and have a read on what else has been done.

I've added LMM-DESC.TXT to the first post, a description of image format and how Cog / overlay code melds into that, and my thoughts on how to do the overlays.

Calls into the overlays and returns shouldn't be too bad, even without a stack. It is possible to write 'something' to where the RET is in Hub Memory instead / as well as in Cog. That would work if there's only one Cog running the LMM kernel and there's no recursion.

The way I envision it is that FARJMP, FARCALL and RETFAR would generate JMPRET's into the kernel followed by a LONG for related Hub Address ( known at compile time ) so the kernel would be able to get all information needed from what's been put into the 'dummy RET' by those FAR instruction opcodes. Using IF_NEVER conditions it should be possible to keep those as single long instructions and expand to create the JMPRET/LONG at overlay load.

I'm hoping to eventually create a generic framework, so how it would be implemented is up to the individual programmer.