So what is the difference between @ and #@ and ##@?
"@" means the-address-of-in-hub.
"#@" means the-address-of-in-hub, in an immediate 9-bit constant. It had better fit!
"##@" means the-address-of-in-hub, in an immediate 32-bit constant (20-bit, really). It will always fit!
I think someone accurately answered this earlier.
Possibly, but with the latest changes, I've lost track. Taking this a bit further, what is the difference between:
# and #@
## and ##@
edit: And where would you use @ instead of #@ or ##@?
#, ##, and @ are all completely separate operators. # means the same as it does on the P1. @ is the same as P1 @@@ (like @ but add object offset). ## is like # but uses AUGS to make values > 9 bits fit.
Try "##(0+(@x))". It should do the same thing as "##@x".
Those nine bits would only reach to $1FF. Remember that we are not forcing long alignment for instructions, like some would prefer, so that we could reduce the PC's by two bits. Those 9 bits count bytes, not longs.
Clear descriptive mnemonics are a lot easier to learn (and read) when working with code that a single one with a bunch of non descriptive conditional symbol characters attached.
Example A___ = Absolute mode, R___ = Relative mode, I___ indirect mode, etc.
They can be grouped together in the documentation with the differences identified. With some standard labeling this is clear across multiple instructions (common theme).
Since a major target here is educational use making things as easy as possible for beginners would seem to be a priority. Gurus already know this stuff like the back of their hands and sometimes forget how something so easy for them can be very hard for a new programmer.
It looks like the DE0-Nano might fit three cogs, but no CORDIC.
I should have this ready soon.
Does anyone have a DEO-Nano, no add-on board, AND a PropPlug? Without a PropPlug, the DE0-Nanos won't work. You need a PropPlug to make it work.
I have two DE0-Nanos and several PropPlugs. On the other hand, don't make a build that doesn't require the add-on board just for me. I have a DE2-115 board as well as a 1-2-3 A7 board that I can use if I can't use the Nano.
...The assembler takes care of the absolute/relative decision now. It uses absolute addresses for cog <--> hub branches and relative addresses for cog <--> cog and hub <--> hub branches.
That sounds a good convention.
Just curious, is a relative opcode silicon-valid to go COG->HUB and HUB-> COG ?
ie does that work, even though Assembler convention will not usually do that ?
I also presume JMPREL Reg
can go to/from any code space ?
...The assembler takes care of the absolute/relative decision now. It uses absolute addresses for cog <--> hub branches and relative addresses for cog <--> cog and hub <--> hub branches.
That sounds a good convention.
Just curious, is a relative opcode silicon-valid to go COG->HUB and HUB-> COG ?
ie does that work, even though Assembler convention will not usually do that ?
I also presume JMPREL Reg
can go to/from any code space ?
It does work! It just seems reckless if anyone made movable code.
That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.
I also presume JMPREL Reg
can go to/from any code space ?
It does work! It just seems reckless if anyone made movable code.
I can see a use case for boundary crossing JMPREL Reg for 'fast case' into COG and error/rare case into HUB.
I'll admit not common, but good to know it works.
Agreed, seems to me that JMP or CALL relative to cross hub/cog boundaries is reckless and asking for trouble. I might go so far as saying it should result in an error/warning.
Actually the same goes for wrapping hub/cog spaces too. It's most likely an error and likely to corrupt cog or worse still hub.
That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.
To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).
That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.
To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).
Does anyone have a DEO-Nano, no add-on board, but still have a PropPlug? Without a PropPlug, the DE0-Nano won't work.
I have a nano, but no add-on board. But I have a PropPlug.
Although I won't be able to play with this until after Nov. 11 (location change), but if possible it would be great if I could, even without the add-on board which I don't have.
Edit: Ah I see an image has already been created while I was still reading and answering older posts. Thanks Chip.
What if you call RDFAST and then WFLONG or WRFAST and then RFLONG, or call WFLONG while in hubexec, or otherwise abuse the FIFO?
Can you insert an instruction into the hubexec stream by calling WFLONG? Will this mess up the PC?
WFLONG might insert an instruction. RFLONG might skip one. Try it and find out.
Testers: These are great types of things to try and find out. Better to have this know up front and either correctable or noted in the documentation than something people puzzle over when the silicon does it!!
An idea for testers and those that have serious questions but no hardware.
If you think of something that would be interesting to try or might be a really good thing to test, put it into a "TRY ME" thread in the P2 section (with some idea of the code if you can) and one of us with hardware could pick it up and work with you in testing it.
I'm not the greatest coder but I'm learning P2 and would be happy to collaborate* with anyone on testing interesting things.
I'm sure we need help from everybody before we can think of everything to test.
Comments
#, ##, and @ are all completely separate operators. # means the same as it does on the P1. @ is the same as P1 @@@ (like @ but add object offset). ## is like # but uses AUGS to make values > 9 bits fit.
Try "##(0+(@x))". It should do the same thing as "##@x".
Or, you could just use it to pass some generic parameter...
Was about to say that I was starting to like the new forum but now can't delete my duplicate message...
Example A___ = Absolute mode, R___ = Relative mode, I___ indirect mode, etc.
They can be grouped together in the documentation with the differences identified. With some standard labeling this is clear across multiple instructions (common theme).
Since a major target here is educational use making things as easy as possible for beginners would seem to be a priority. Gurus already know this stuff like the back of their hands and sometimes forget how something so easy for them can be very hard for a new programmer.
I should have this ready soon.
Does anyone have a DEO-Nano, no add-on board, but still have a PropPlug? Without a PropPlug, the DE0-Nano won't work.
Just curious, is a relative opcode silicon-valid to go COG->HUB and HUB-> COG ?
ie does that work, even though Assembler convention will not usually do that ?
I also presume
JMPREL Reg
can go to/from any code space ?
It does work! It just seems reckless if anyone made movable code.
That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.
I can see a use case for boundary crossing JMPREL Reg for 'fast case' into COG and error/rare case into HUB.
I'll admit not common, but good to know it works.
IIRC JMPREL Reg is a PC relative jump for things like fast table-case statements.
could also be written
JMP PC+[Reg]
Actually the same goes for wrapping hub/cog spaces too. It's most likely an error and likely to corrupt cog or worse still hub.
To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).
Good idea.
Although I won't be able to play with this until after Nov. 11 (location change), but if possible it would be great if I could, even without the add-on board which I don't have.
Edit: Ah I see an image has already been created while I was still reading and answering older posts. Thanks Chip.
-Tor
Confirm both DE0_Nano configurations working OK .
Thanks for the new images.
Cheers
Brian
Brian, thank you for testing those.
Can you insert an instruction into the hubexec stream by calling WFLONG? Will this mess up the PC?
WFLONG might insert an instruction. RFLONG might skip one. Try it and find out.
Testers: These are great types of things to try and find out. Better to have this know up front and either correctable or noted in the documentation than something people puzzle over when the silicon does it!!
If you think of something that would be interesting to try or might be a really good thing to test, put it into a "TRY ME" thread in the P2 section (with some idea of the code if you can) and one of us with hardware could pick it up and work with you in testing it.
I'm not the greatest coder but I'm learning P2 and would be happy to collaborate* with anyone on testing interesting things.
I'm sure we need help from everybody before we can think of everything to test.
*I get point if I use this word at work!!!
quick question: are PTRA and PTRB regular cog registers, or are they shadow registers?
They are discrete hardware registers on read and write. Their shadow registers are never used.
Z = bit state
C = not bit state
Edit: Correction
This is what I'm seeing: