big endian confusion in gear.exe

Fred Hawkins

I thought I grasped this little-endian business. And I learned that assembly language as shown in the F8 view would be backwards (byte by byte)·from the manual's opcode bit breakdown.

But then I was running gear today and, yup, its display of the opcodes in cog memory·looks like the manual's.

So I am wondering. Does gear get it 'wrong'? Or do the·hub and cog memories swap endian-ness? For that matter,·what·do·the .binary files look like?

___________
A·32 bit number in gear's view of cog memory is shown as·big-endian. But a byte string is backwards.

I am thinking that gear shows each long of cog memory backwards for convenience's sake. Otherwise the string bytes don't make much sense.



Post Edited (Fred Hawkins) : 11/19/2007 5:48:29 PM GMT

mirror

Fred Hawkins said...

I am thinking that gear shows each long of cog memory backwards for convenience's sake. Otherwise the string bytes don't make much sense.

Fred, I don't quite understand your question, but the way the byte string as shown in cog memory makes it easier to scan the list of opcodes in the Assembly Language Reference section of the Propeller Manual.

If I haven't answered sensibly, then try asking the question again, but differently - if I can understand your question, then I can probably give you a proper answer. It is possible that something is not quite right in Gear, but the original author of the software has not been seen for quite some time on this group. I've made changes to the source code, and am quite happy to keep making (minor) changes if there's stuff that's wrong.

Fred Hawkins

Thanks mirror, I was feeling like a falling tree in the woods.

This picture is too big, but it has all the pieces with, like Arlo sings, circles and arrows and paragraph about each on the back.

BigEndian that I am, I am secretly hoping that the Little Endian-ness is an artifact of the hub memory and when stuff is moved to cog's memory, it's restored to an orderly bunch of Big Endian longs. (teeth gnashing, grasping at every little blade of grass, over the edge into Little Endian doooooom)

Post Edited (Fred Hawkins) : 11/20/2007 4:19:01 AM GMT

mirror

Fred,

The horrible answer is that everything looks fine!

I guess the major confusion is that the HUB memory is accessible as bytes (as well as words and longs), BUT the COG memory can ONLY be accessed as longs. As a result of this: In the disassembly display there's no point in showing the memory contents as anything other than longs - they effectively don't have an endieness.

---

I guess there's a reason for needing to know this detail, as in practice it doesn't tend to affect the way I write my Propeller code. Maybe you could share the underlying problem, which may lead to a better answer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

mirror

Fred,

I think the confusion is caused by the:
byte "this is a test line"

In practice, it doesn't really work all that well. Not that it's impossible, but you have to shift your bytes out from the correct side of the long that's been stored into the COG memory. To re-iterate, there's no way of accessing your byte string other than by doing shifts and masks from within the assembly code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

deSilva

Fred,
you are quite right (and Mirror as well )

There is a general misunderstanding that HUB memory (in contrast to COG) memory is byte-organized. That is not true .

The difference is, that you have some extra logic to select "byte 0", "byte 1", "byte 2", "byte 3" and "word 0" , "word 1" from a LONG, when accessing HUB memory - you do not have this option when accessing COG memory,so any problem is hidden from you there.

For some reason, byte 0,1,2 and 3 are positioned in a "natural" order within a byte when using GET (or PUT) BYTE
Byte 0 = bits 0..7
Byte 1 = bits 8..15
Byte 2 = bits 16..23
Byte 3 = bits 24..31

This seems confusing as you expect any "string" to enter a word from left-to-rigth (though you do not expect this for a binary number!)

Of course the "byte-access logic" could have been done in a different way (Byte 0 = bits 24..31, ect), counting the Bytes from "High" to "Low", which would be very unnatural, after some thought...

I do not know the (most likely technical) rational why Parallax has chosen the "natural" concept...
----
A historic argument for this on other machines has to do with their 8 bit I/O bus. When working with 16-bit words you wanted to output the lower "byte" 0..255 to the I/O device, not the higher, so the lower byte got the lower address..

Post Edited (deSilva) : 11/20/2007 8:36:09 AM GMT

Fred Hawkins

Thanks. Here's what I understand: gear's display is intended to ease looking up the manual's opcodes. The specific byte order is as shown in this second gif.

Mirror's second point (as is deSilva's): don't sweat it, the programming takes care of it without any particular worry.