I had forgotten about ORGF. I fill with longs using a variable size based on $.
Yes, we’re just wanting to suppress the error, but the current compilers might not have the ability to continue.
Could we have a FITH for testing the current hub address?
One thing I’ve noticed over the past week is that there are some traps for making code executable as both hubexec AND cogexec. Jump and call and the DJNZ and variations - relative addressing doesn’t seem to work for both cog and hub - it’s an either or case. I didn’t look deeply, but it’s possible the relative addressing is in bytes for hub and longs for cog.
This leads me to ponder, is it useful to be able to have hub code compiled for a different hub address. BTW, I’m sure Eric will be ducking for cover about now! We used to compile relocatable code and then link it to its final address.
completely unrelated - thinking over @JonnyMac's last project, we need a new SECtion for the define ifdef and stuff like that, maybe -e or other directives.
This leads me to ponder, is it useful to be able to have hub code compiled for a different hub address. BTW, I’m sure Eric will be ducking for cover about now! We used to compile relocatable code and then link it to its final address.
Well, fastspin does have -H and -E options for setting the base address of the executable code (so you can compile it to run at any fixed address). You could use that now for overlays. @msrobots used those switches for getting fastspin compiled code to work with TAQOZ.
Truly relocatable code would be very useful, but that's a bit more work in the compiler (if you're just writing PASM you can already achieve this, of course ).
I...One thing I’ve noticed over the past week is that there are some traps for making code executable as both hubexec AND cogexec. Jump and call and the DJNZ and variations - relative addressing doesn’t seem to work for both cog and hub - it’s an either or case. I didn’t look deeply, but it’s possible the relative addressing is in bytes for hub and longs for cog.
Relative-constant branches are encoded the same for cog and hub code.
I can't remember at the moment if the same is true for absolute-constant branches. Anyone know?
Thanks Chip. I thought relative should have worked so maybe I had absolute coding, or another bug. I'll check it out later.
Absolutes would be different address results though, depending on whether the code is in cog or hub space.
So these wouldn't work for the same code designed to run in both spaces.
Those hubexec time comparisons with cog are great news. No 4x penalty for lmm mode anymore
Comments
Yes, we’re just wanting to suppress the error, but the current compilers might not have the ability to continue.
Could we have a FITH for testing the current hub address?
One thing I’ve noticed over the past week is that there are some traps for making code executable as both hubexec AND cogexec. Jump and call and the DJNZ and variations - relative addressing doesn’t seem to work for both cog and hub - it’s an either or case. I didn’t look deeply, but it’s possible the relative addressing is in bytes for hub and longs for cog.
This leads me to ponder, is it useful to be able to have hub code compiled for a different hub address. BTW, I’m sure Eric will be ducking for cover about now! We used to compile relocatable code and then link it to its final address.
And in a COG we do not need it there the existing ORG and ORGF are fine.
Mike
So a spin program would start with
Just saying...
Mike
Well, fastspin does have -H and -E options for setting the base address of the executable code (so you can compile it to run at any fixed address). You could use that now for overlays. @msrobots used those switches for getting fastspin compiled code to work with TAQOZ.
Truly relocatable code would be very useful, but that's a bit more work in the compiler (if you're just writing PASM you can already achieve this, of course
ORGH $ < $400 ? $400 : $
Wow Chip!
You've been hiding that little gem from us.
That "Verilog" style condition test works great!
That changes my whole thinking on P2 assembler.
Anything else you're not telling us about Pnut, Chip? : )
I don't think so. I just remembered that ternary operator.
Man, maybe I already finished Spin2, but I haven't remembered, yet.
Relative-constant branches are encoded the same for cog and hub code.
I can't remember at the moment if the same is true for absolute-constant branches. Anyone know?
Absolutes would be different address results though, depending on whether the code is in cog or hub space.
So these wouldn't work for the same code designed to run in both spaces.
Those hubexec time comparisons with cog are great news. No 4x penalty for lmm mode anymore
In fastspin that has to be: due to ambiguity around the "?" operator (fastspin still supports Spin1). But it otherwise works fine, so I guess we can shelve this discussion
Thanks for remembering this Chip!
Interesting...