Propeller Memory-Organization Question.

JonTitus

I'm helping students understand the Propeller I software and will soon explain how pointers work. Unfortunately I cannot find a diagram that shows how the Propeller saves bytes in memory (little-endian) and assigns them addresses or pointers. So far I assume bytes in an array get stored as shown in the diagram I have included below. But, does the Propeller assign addresses as shown, or does it use the physical address for a 32-bit memory location and then use an "offset" to indicate the array element to extract from the 32-bit location. I want to ensure students get the correct information. Thanks for helping. --Jon

Mike Green

As far as you're concerned, hub memory is byte addressable. When you produce an address, it's the address of a single byte as you showed in your diagram. The actual hardware is organized as 32-bit long words, but the hardware handles all of the packing and unpacking of these as bytes and 16-bit words. The RDWORD and WRWORD instructions ignore the least significant bit of the byte address and these fetch and store 16-bit words. The RDBYTE and WRBYTE instructions use the whole byte address. The RDLONG and WRLONG instructions ignore the two least significant bits of the byte address and fetch and store 32-bit long words.

Note that when Spin compiles variable addresses into constants (as in a DAT section), it stores the offset of the variable from the start of the variables in the object, not the absolute address of the variable. The "@@" operator is used to correct this at run-time. Look at the description of the "@@" operator in the Propeller Manual.

JonTitus

Thanks for clarifying the memory organization, Mike. Very helpful information. I appreciate your fast reply. --Jon

LoopyByteloose

If you load Forth into a Propeller, you can easily explore this with cog@ and cog!, @ and ! and so on.

I had a lot of difficulty with just reading texts and accepting what the Propeller is supposed to do. I found it quite delightful that I can now interactively PEEK and POKE to just about any memory locations. Non-destructive hacking is a valid educational tool.

Cog Dumps, Hub RAM Dumps and EEprom Dumps are all useful as well

I am using pfth version 1.00 now, but PropForth V5.5 and Tachyon 2.x are equally worthy of considering. I am sure that students will gain more confidence if they can actually confirm where things go, what is present, and when bytes, words, and longs are most useful.

Rayman

You can use pointers and offsets, BTW...

Things like: pByte:=@ByteArray
and then: Byte5:=byte[pByte+5] or Byte5:=byte[pbyte][5]