Never mind again, sorry. Figured it out... I had added a delay in the serial routine that was holding things up...
The serial cog is just for debugging, but the way it is now, the graphics cog waits for the serial cog to process before continuing...
I had added a delay in the serial cog when trying to figure out the previous issue and forgot to remove it.
Does LOC have any syntax to distinguish between load the value, and add the value to PC (PC relative)?
If not, shouldn't it be two distinct instructions?
Edit:
let's look at disassembly. Would the slash have to be printed next to the constant to say it's direct addressing? So then you use ## and it's now a compound instruction. But since that is printed prior to LOC you'd always have to be looking ahead for it specifically.
So yeah, why wouldn't LOC just be the PC relative, and LEA just be the load direct?
The LOC worked correctly for Rayman. It wasn't the issue.
## won't work on LOC just like it won't work on long branching either. Interestingly, Pnut gets a typical cryptic error but Fastspin just nose dives into bad code generation that crashes.
OK, that clears that part up.
But at the same time, again how would a LOC that's PC relative and a LOC that's absolute be shown in a disassembly without symbolic labels?
It still feels like it would need two different opcodes.
OK, that clears that part up.
But at the same time, again how would a LOC that's PC relative and a LOC that's absolute be shown in a disassembly without symbolic labels?
It still feels like it would need two different opcodes.
It's no different to the immediate "#" operand prefix
The PC-relative encoding just means relative from the following instruction. Don't even need to know where in memory you are to know where it points within the disassembled file.
I have these spin objects that I want to compile for P2 ASM. How do I do it?
I tried fastspin filename -2 -l --fcache=0 but it deletes the unused PUBs and hence most PRIs too.
So I tried the -O0 option without success.
It compiles but there isn't much output
Never mind again, sorry. Figured it out... I had added a delay in the serial routine that was holding things up...
The serial cog is just for debugging, but the way it is now, the graphics cog waits for the serial cog to process before continuing...
I had added a delay in the serial cog when trying to figure out the previous issue and forgot to remove it.
Glad you got it sorted out. Thanks for your help debugging this!
I have these spin objects that I want to compile for P2 ASM. How do I do it?
I tried fastspin filename -2 -l --fcache=0 but it deletes the unused PUBs and hence most PRIs too.
So I tried the -O0 option without success.
It compiles but there isn't much output
I'm not sure exactly what you're trying to do here... do you want fastspin to just translate from Spin to PASM but not compile the code to binary? If so then there are a few options; which one is best probably depends on what you're trying to achieve.
In general for translating between source languages (Spin/BASIC/C to PASM or C) use the spin2cpp frontend instead of fastspin. For example to just look at how fastspin/spin2cpp is translating some Spin to PASM I usually use:
spin2cpp --p2 --asm foo.spin
which produces the "foo.p2asm" assembly file. You can also add "--code=hub" to force hubexec code, although for P2 this makes very little difference.
For the somewhat niche case of automatically producing a COG object from some Spin code you can use the "-w" option to fastspin to convert the Spin to PASM with wrappers around it. That option doesn't get used much so it may have some rough edges.
Eric,
I just used this trick (works) with fastspin
sd_tristate = $F << ((sd_do > 31) ? (sd_do-32) : (sd_do)) 'WARNING: presumes contiguous and DO lowest!
dirab = ((sd_do > 31) ? ($1FB) : ($1FA)) 'select DIRB or DIRA register
andn dirab, ##sd_tristate ' tristate CS/CK/DI/DO
Do you know of an easier way?
BTW I still need to check if the pins are sequential (later)
And of course the new silicon can handle this.
How do I force a compile error?
_sequence1 = ((sd_ck > sd_cs > sd_di > sd_do) ? 0 : (?)) ' force an error if not in sequence
_sequence2 = ((sd_ck == (sd_do+3)) ? 0 : (?)) ' force an error if not sequential
Instead of forcing a compile error, can't you just make the interface such that only the DO pin is specified explicitly and the other three are calculated from that?
Eric,
I seem to have hit a wall with including spin objects (a pasm file).
How do I get the hub starting address so that I can load the program with COGINIT?
Of course I went around a loop because I used the same names so I was just restarting my own cog
The usual way is:
DAT
org 0
entry
...
PUB start
cognew(@entry, args)
But I know you know that, so I guess you're trying to do something different. Could you explain what you're after? Does "@" not work somehow for your use case?
Eric,
Also including an object at the end of the program - fastspin ignores the code and compiles without warning.
Is the object used? If not, it's just being removed as unused code.
I don't understand your overall objective. Are you trying to convert some Spin code to PASM and then hoping to re-use that PASM? If so, may I ask why? The original Spin code would be easier to maintain.
So, I thought the latest fastspin posted here fixed my loc with hubexec issue, but it seems not...
I guess the problem with getting addresses to embedded DAT objects is fixed, but using LOC to load a constant hub address doesn't work the same way in cog exec as it does in hubexec…
Here's the hubexec code that has the issue:
DAT 'Fillbottom
FillBottom 'RJA: just the bottom now that floorcasting is working
loc ptrb,#OffscreenBufferAddress 'image buffer
'loc ptrb,#\OffscreenBufferAddress 'image buffer
OffscreenBufferAddress is just a fixed location defined like this:
CON 'graphics constants
OffscreenBufferAddress=$40000 '320x240 =$12C00
DisplayBufferAddress=$50000+$3000 'size is 320x240=$12C00 (was 640x480=$4B0000)
Using either the backslash or "##" fixes it. But, it seems to not need this in cog exec code...
Comments
Only thing I see now is that the FPS is 30% slower now that as objects instead of all in one file with cogs started by assembly instead of spin.
Any reason this could be?
The serial cog is just for debugging, but the way it is now, the graphics cog waits for the serial cog to process before continuing...
I had added a delay in the serial cog when trying to figure out the previous issue and forgot to remove it.
68000 assembler had cute opcode names anyway
ANDI, PFLUSH, ILLEGAL I actually like BRA more then jmp
ABCD is also nice, FATAN also...
Mike
I think Samsung implemented this one in a recent phone
You might be thinking of the MC6802 with HCF = Halt and Catch Fire
Also known as Drop Dead because it is encoded as 0xDD
https://en.wikipedia.org/wiki/Halt_and_Catch_Fire
Maybe they shouldn't have built a MC6802 feature into the Note 7 :-D
If not, shouldn't it be two distinct instructions?
Edit:
let's look at disassembly. Would the slash have to be printed next to the constant to say it's direct addressing? So then you use ## and it's now a compound instruction. But since that is printed prior to LOC you'd always have to be looking ahead for it specifically.
So yeah, why wouldn't LOC just be the PC relative, and LEA just be the load direct?
## won't work on LOC just like it won't work on long branching either. Interestingly, Pnut gets a typical cryptic error but Fastspin just nose dives into bad code generation that crashes.
But at the same time, again how would a LOC that's PC relative and a LOC that's absolute be shown in a disassembly without symbolic labels?
It still feels like it would need two different opcodes.
I have these spin objects that I want to compile for P2 ASM. How do I do it?
I tried fastspin filename -2 -l --fcache=0 but it deletes the unused PUBs and hence most PRIs too.
So I tried the -O0 option without success.
It compiles but there isn't much output
But, now it is fixed, so I don't need the backslash.
Still, another way might have been to always use the backslash.
Glad you got it sorted out. Thanks for your help debugging this!
I'm not sure exactly what you're trying to do here... do you want fastspin to just translate from Spin to PASM but not compile the code to binary? If so then there are a few options; which one is best probably depends on what you're trying to achieve.
In general for translating between source languages (Spin/BASIC/C to PASM or C) use the spin2cpp frontend instead of fastspin. For example to just look at how fastspin/spin2cpp is translating some Spin to PASM I usually use: which produces the "foo.p2asm" assembly file. You can also add "--code=hub" to force hubexec code, although for P2 this makes very little difference.
For the somewhat niche case of automatically producing a COG object from some Spin code you can use the "-w" option to fastspin to convert the Spin to PASM with wrappers around it. That option doesn't get used much so it may have some rough edges.
Just looking for spin2cpp?
There was a recent issue identified when using Spin to start assembly with hubexec.
ersmith fixed it and posted a new fastspin.exe in this thread.
If you look at garryj's USB code for Spin, you can see how he needed to use the backslash in his hubexec code.
I just used this trick (works) with fastspin
sd_tristate = $F << ((sd_do > 31) ? (sd_do-32) : (sd_do)) 'WARNING: presumes contiguous and DO lowest! dirab = ((sd_do > 31) ? ($1FB) : ($1FA)) 'select DIRB or DIRA register andn dirab, ##sd_tristate ' tristate CS/CK/DI/DODo you know of an easier way?BTW I still need to check if the pins are sequential (later)
And of course the new silicon can handle this.
How do I force a compile error?
For PASM that seems like a reasonable way to do it. For Spin I would just use:
PUB tristate1 if sd_do > 31 dirb &= !(1<<(sd_do - 32)) else dira &= !(1<<sd_do)which, if sd_do is constant, will end up generating the same code, something like (for sd_do == 35):_tristate1 andn dirb, #8 _tristate1_ret retaI seem to have hit a wall with including spin objects (a pasm file).
How do I get the hub starting address so that I can load the program with COGINIT?
Of course I went around a loop because I used the same names so I was just restarting my own cog
Also including an object at the end of the program - fastspin ignores the code and compiles without warning.
The usual way is:
DAT org 0 entry ... PUB start cognew(@entry, args)But I know you know that, so I guess you're trying to do something different. Could you explain what you're after? Does "@" not work somehow for your use case?Is the object used? If not, it's just being removed as unused code.
I don't understand your overall objective. Are you trying to convert some Spin code to PASM and then hoping to re-use that PASM? If so, may I ask why? The original Spin code would be easier to maintain.
I guess the problem with getting addresses to embedded DAT objects is fixed, but using LOC to load a constant hub address doesn't work the same way in cog exec as it does in hubexec…
Here's the hubexec code that has the issue:
DAT 'Fillbottom FillBottom 'RJA: just the bottom now that floorcasting is working loc ptrb,#OffscreenBufferAddress 'image buffer 'loc ptrb,#\OffscreenBufferAddress 'image bufferOffscreenBufferAddress is just a fixed location defined like this:
CON 'graphics constants OffscreenBufferAddress=$40000 '320x240 =$12C00 DisplayBufferAddress=$50000+$3000 'size is 320x240=$12C00 (was 640x480=$4B0000)Using either the backslash or "##" fixes it. But, it seems to not need this in cog exec code...