Pnut Assembler Bug - Immediate representation of cog address labels
ozpropdev
Posts: 2,793
in Propeller 2
Hi Chip
If I refer to a cog address by name as an immediate it fails. If I manually enter the cog address it works.
An example
Test result for manually coded immediate value
Results of Pnut's immediate assignment
If I refer to a cog address by name as an immediate it fails. If I manually enter the cog address it works.
An example
mov regy,#one 'fails mov regy,#$30 'worksSee attached demo program
Test result for manually coded immediate value
Prop2 "ALTDS" instruction test #1 regy = 00000030 -=> Results <=- 11111111 22222222 33333333 44444444 55555555 66666666 77777777 88888888
Results of Pnut's immediate assignment
Prop2 "ALTDS" instruction test #1 regy = 000000C0 -=> Results <=- 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Comments
I think when you do '#one' you are getting the byte-oriented address. To get the register, you'd need to do '#one>>2'. At least, that's a problem I see.
This byte-oriented addressing is a pain, in some ways.
Mind was in old cog mode. I forgot about the new byte addressing model.
Sure, but then we've got another problem:
How to handle JMP #label?
What if it's a hub address that uses the two LSB's?
We can make all kinds of patches, but we need a fundamental change to make things really straight.
While on the subject of making things nice and easy, I was playing with ALTDS today.
One idea on a supporting syntax for this instruction was along these lines.
mov regx,(regy) 'use s value in regy to replace original s value mov regx,(regy++) 'same as above but with increment add regx,regy `newreg 're directs result to field supplied by newreg .. and similar for d-field mov (regy),#0 ...etcLike the AUGx implementation currently in Pnut these would generate ALTDS instructions.
Cleans code up and eliminates remembering the ALTDS modes.
Just an idea...
A good start would be to make the Address without the #, ( just like nearly all other assemblers do )
Then, you could introduce an ADR() operator for loading an address for index use.
User intent is clear, and assembler checks for segment and applies requires >> if any.
I've been thinking pretty much the same thing. A way to hide all the ugliness and make it easy to use.
What's really eating me up at the moment is this issue of cog registers being located at 1/4 of the measured address. This creates all sorts of nasty gotchas. We need a long-based machine that can address byte and word data, as well. It seems like we have it backwards.
Maybe you could default to implicit long, and use something like
ByteAdr(ByteVariableName)
WordAdr(WordVariableName)
for the other cases loading ?
Perhaps.
What P2-Hot did was track long addresses for PC use (got rid of two LSBs), and then had instructions which could take PC values and shift them left two bits and add offsets for array lookups, and what not. It worked pretty well. I just can't get over the estrangement from not being able to call out cog registers by their numbers.
That is a rare usage, as most ASM code reserves locations by name, and then uses the VarName as the reference.
Same with Labels.
The tools can then do pretty much what you describe P2 hot silicon as having done.
I think the silicon has to 'think in bytes', but the tools do not need to use bytes as the default - the most common usage would be a better default.
Then please make all instruction addresses long-aligned. Why do we even need misaligned instructions? It won't save any significant amount of memory. Also, forcing instructions to be long-aligned doesn't have to disallow non-aligned data accesses (unless I have no idea how streamer addressing works) - keep the hub streamer how it is now, and feed it {pc, 2'b00} as the address when doing hubexec.
I'm sure many if not most would disagree with me on this last part, but I would actually prefer long addressing for cog/lutram and byte addressing for hubram over consistent byte addressing for both.
Hubexec is not the main feature of the P2. In fact, it is arguably the least unique feature about the P2 - it's all most processors have. It should not dictate how everything else works.
Yes x 10. It is distressing to me to see everything else compromised for hubexec. But then that has been a fundamental split among Prop users for a long while. My privately held opinion has been that if hubexec is your thing, you might do well to look into an ARM.
I think I've read every word that Chip has ever posted to the Forum, and while I don't have perfect recall (not even close), the overall impression has always been that features have their costs.
If hub exec is a true freebie (other than the addressing complications) I'll shut up right now.
Actually, I'll probably shut up anyway.
It actually was almost free, after implementing the eggbeater hub memory scheme. When I went to connect it up for hub exec, it was literally a line of Verilog here, a line there, and one over there. I thought it was, somehow, going to be a lot more complicated than that. The eggbeater was needed for other features, as well, so it wasn't hub-exec-centric.
Good point. It did turn out to be pretty simple, though, once the eggbeater was there to serve a few other necessary purposes, as well.