PAR(ameter) Value
pjv
Posts: 1,903
Hello Chip;
Is there a reason why the Par(ameter) value passed on launching a new COG must have the two·least significant bits·cleared? I understand that main memory addresses require "long" boundaries implying zeros for those bits,·but when PAR is used for something other than an address, the LSB zeros are a bit of a pain.
As long as·the programmer is aware of the "long" boundary requirement, and properly deals with that, could a next rev of silicon have those two bits enabled? Or perhaps·there is some inherent issue that I don't understand that prevents this.
Cheers,
Peter (pjv)
·
Is there a reason why the Par(ameter) value passed on launching a new COG must have the two·least significant bits·cleared? I understand that main memory addresses require "long" boundaries implying zeros for those bits,·but when PAR is used for something other than an address, the LSB zeros are a bit of a pain.
As long as·the programmer is aware of the "long" boundary requirement, and properly deals with that, could a next rev of silicon have those two bits enabled? Or perhaps·there is some inherent issue that I don't understand that prevents this.
Cheers,
Peter (pjv)
·
Comments
Yes, there is a reason for this. In the COGINIT instruction, the 'D'estination register conveys three things: which/new COG to start (4 bits), a long load address (14 bits), and a long PARameter address (14 bits). That all adds up to 32 bits. I, too, have had occasions where 16-bits would have been handy to convey via PAR. In the next generation, there is quite a bit more global memory, so the 'S'ource register will have to be used to convey some data, too. I think that in that case, where there are not such bit constraints, we could convey an 18-bit·byte address (working lsb's) for PAR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.