Pepper SPIN with Assembly?
Humanoido
Posts: 5,770
I'm writing some arbitrary SPIN code and I see lots of small
snippets of assembly code that I would like to use, like this.
To what degree can these small snippets of assembly
code, without any other support, be mixed with SPIN?
Thank you in advance.
Humanoido
snippets of assembly code that I would like to use, like this.
MOV $1F4, #$FF 'Set OUTA 7:0 high
To what degree can these small snippets of assembly
code, without any other support, be mixed with SPIN?
Thank you in advance.
Humanoido
Comments
Problem is that to run any PASM instructions you have to get them loaded into a COGs memory space first.
The Cog that is executing your Spin code is already full, with the Spin byte code interpreter. Even if it were not full it's unlikely any one would design the interpreter to suck in any old instructions and run them [See note 1].
So you would have to load that PASM into a different COG. But you can only load a whole COG (496) LONGs so it would be a slow process just for a couple of instructions.
Even if you do that you are then left with the problem of communicating with that PASM snippet through HUB memory. It's just not worth it.
So result is "Not at all."
Note 1: I'm considering allowing the Zog byte code interpreter for C to allow loading and executing of any PASM instruction as it runs. Not intended for use by application programs but as a way for C code to be able to do waitxxx and hubops like COGINIT etc.
version of the spin interpreter that allows this?
Store this version on the upper half of a 64kb eeprom, and load a cog with it
and end the current rom based interprete cog.
I'd find this sort of thing useful, for both writing programs, and also for learning pasm, as you could take a single pasm instruction and put it in amongst some high level code that might read a keyboard, or print something to a screen, and then you can experiment with pasm and debug code fragments more easily.
... but for small code snippets, this has been working really nice for me. It might help others as well.
http://obex.parallax.com/objects/665/
or in the code below...
Humanoido
http://obex.parallax.com/objects/635/
And some sample objects
http://obex.parallax.com/objects/636/
Massimo
I haven't fully absorbed what you have done there but it possible to get rid of the need for manually tracking jump target addresses by using ORG. Like this snippet which creates the correct run time jump address in the Pasm1 routine:
Basically what you have here is a PASM overlay loader controlled from Spin, sneaky.
Anyone who wants to do this should check out the tricks used in Cluso's overlay loader. From which I learned the ORG thing:)
Don't be. This is "Propeller Land" where impossible things are done every day.
Notice some idiot in this thread hastily replied "Not at all." to your question:)
It has indeed become a roller coaster ride of ups and downs, of yes's and no's, possible and impossible, blinded guessing and grand visions spot on, a place where you'll meet pure genius from above and hot-hard-heads from down below, where fame is fleeting and success is lasting, a place to get flamed one day and praise-honored the next.. welcome to the Propeller Forum!
Humanoido
Humanoido
When I read around the forum the opinion that propeller power hasn't been fully unleashed I was sceptical... while in fact anything considered impossible for the propeller becomes possible in an impressively short time.
There are also a couple of objects around in development that could be described as multitasking, if the word wasn't banned from this forum... :-) It means anyway we will probably have in the near future the possibility to use one single COG in place of the 2-4 COGs required until now for the same tasks...
Both the dispatcher and the inline assy, while not for starters, will bring a lot of power.
Massimo