PBASIC 2.5 Alias Semantics: Missing Intuitive Options?

Phil Pilgrim (PhiPi)

This should be simple. I've got a 7-byte array named char. I want to share the first two elements with a couple scratch variables, scr0, and scr1. Here's my first, very intuitive approach:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

char  VAR Byte(7)
scr0  VAR char(0)
scr1  VAR char(1)

Nope: compiler wags its finger at the (0) subscript. Okay, that seems rather arbitrary, but I've got another option:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

char  VAR Byte(7)
scr0  VAR char.LOWBYTE(0)
scr1  VAR char.LOWBYTE(1)

'Still doesn't like the subscript. So I try this:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

char  VAR Byte(7)
scr0  VAR char.BYTE0
scr1  VAR char.BYTE1

Nope again: compiler points to the BYTE0 complaining that it wants a smaller-sized modifier than the Byte that char is defined as. But why?

Okay, if it wants something smaller, my last resort:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

wchar VAR Word(4)
char  VAR wchar.BYTE0
scr0  VAR wchar.BYTE0
scr1  VAR wchar.BYTE1

The compiler likes it, but I don't. I've reserved eight bytes for char, when I only needed seven. And what if char and the scratch variables had needed to be Words instead of Bytes? Furthermore, what if I had need a scr2? There's no BYTE2 modifier available for that.

Okay, I know I can get where I want to go with something like this:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

scr0  VAR Byte
scr1  VAR Byte
dummy VAR Byte(5)
char  VAR scr0

But this is bad, bad, bad. It assumes that variables of like size are allocated in order of appearance (which they happen to be), but that's a hidden rule (i.e. not obvious from the program itself).

The more intuitive approaches are logical, consistent, and should just work; but they don't. OTOH, even though I've had my coffee, I may be missing something obvious. I do hope so.

-Phil

Tracy Allen

Hi Phil,

You'll have to take it up with Jeff about aliasing to array variables. But I have simply accepted the workaround of using implicit arrays, which works beautifully.

scr0 VAR byte
scr1 VAR byte
scr2 VAR byte
scr3 VAR byte
scr4 VAR byte
scr5 VAR byte
scr6 VAR byte
charray VAR scr0  ' 7 byte array overlays scr0 to scr6

IMHO, it is not even ugly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

Well, I guess we can agree to disagree about aesthetics. It just pains me that things could be better than they are, without breaking anything. PBASIC 2.6 maybe? I hope so!

-Phil

Tracy Allen

Aesthetics? The array variables as you point out are kind of an afterthought in PBASIC syntax. Implicit arrays are so much more flexible and allow multiple overlays for different purposes. I agree it is not standard and I don't know why the method you prefer doesn't work, but I don't even consider the implicit methods as workarounds any more. The Stamp memory map is aesthetically and impeccably symmetric, and implicit arrays go with the flow.

BTW, some time ago in some thread, you had made observations about counterintuitive behavior in the parsing of WAIT strings in SERIN commands, with repeating characters. Do you recall that thread, where it is?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

Is this the thread you're referring to?

··http://forums.parallax.com/showthread.php?p=628740

-Phil

Tracy Allen

That's it, thanks. I wanted write that note in margin of the manual. My mental binder is loose leaf and things often fall out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

Heh, I know what you mean. But it's not all bad. If I forget the page was ever there to begin with, the joy of rediscovery is just as thrilling as seeing it the first time!

-Phil

Jeff Martin

Hi Guys,

Yes, this is a bit backwords, but does work reliably.·

Here's how I would do it:

' {$STAMP BS2pe}
' {$PBASIC 2.5}

scr0  VAR Byte     '1st byte of 7-byte array
scr1  VAR Byte(6)  '2nd through 7th bytes
char  VAR scr0     'Alias to first byte

It doesn't matter that scr1 will only be referenced as a single character.· Incidentally,·the BASIC Stamp 2 (and above) always treats any reference to a variable as a base+offset operation, regardless of whether it was actually defined as an array or not.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Phil Pilgrim (PhiPi)

Jeff,

'Any chance of a change in the next version of PBASIC?

-Phil

Tracy Allen

Whew! That mixing of fixed and explicit array variables makes my head spin! But even if I had the next version, I don't know if I would find it more useful than the flexibility of base+offset implicit in PBASIC 2.5. What I mean...

scr0 VAR byte
scr1 VAR byte
scr2 VAR byte
scr3 VAR byte
scr4 VAR byte
scr5 VAR byte
scr6 VAR byte
charray VAR scr0    ' 7 byte array overlays scr0 to scr6
rtcArray VAR scr0  ' another 7 byte array overlays scr0 to scr6 for use at another time
adcArray VAR scr3  ' another byte array contains up to 4 bytes and starts at scr3
nibArray VAR scr0.nib0   ' a nib array starts at scr0.nib0, potentially 14 nibs within this structure
pointer VAR scr6   ' alias name for scr6 for local routine
innerIdx VAR scr5.nib0  ' alias name, to use a nib index
outerIdx VAR scr5.nib1  ' and a second nib index

The same set of physical memory locations serves multiple purposes, both as as single variables , different sizes, as well as arrays. Efficient use of limited Stamp ram. That could also be done in a syntax that starts with an array like char(8), and creates aliases off of that, but it is still no more or less messy when it has to serve lots of purposes.

My program template starts by defining a set of word variables, because word variables are always first in memory and stay put, even if other scratch variables of any size are defined later. Some of the initial words are fixed in purpose as pointers and status flags, while others serve different local purposes as tasks come up in the program flow. Sometimes they are used individually, as in acquiring data from an ADC, and sometimes as an array with different sizes of elements, such as retrieving a byte string from a real time clock and then processing it as an array of nibs. There is lots of exchange, getting and putting values from scratchpad RAM. When the scope of a task that uses a variable is very limited, local, I usually don't even bother to give it a separate alias name, just a note in a comment. I find that less prone to error than keeping track of what alias is associated with which physical memory location. The small mind model, close to the hardware. It works for me, anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

When I programmed the Scribbler template, I simply gave up tyring to let the compiler do the allocation. The code below is what I ended up with. I guess it's the only way to get absolute control over where things go. And there's no mistaking how much memory is left over, either. It would be interesting, though, to come up with a spreadsheet-type app that lets you enter the allocation table graphically and writes the code for it. Hmmm.

But all these other techniques notwithstanding, I would still like to see array element aliasing.

-Phil

ScrW0           VAR W0
ScrW1           VAR W1

ScrB0           VAR ScrW0.LOWBYTE
ScrB1           VAR ScrW0.HIGHBYTE
ScrB2           VAR ScrW1.LOWBYTE
ScrB3           VAR ScrW1.HIGHBYTE

ScrN0           VAR ScrB0.LOWNIB
ScrN1           VAR ScrB0.HIGHNIB
ScrN2           VAR ScrB1.LOWNIB
ScrN3           VAR ScrB1.HIGHNIB

ScrT0           VAR ScrB3.BIT0
ScrT1           VAR ScrB3.BIT1
ScrT2           VAR ScrB3.BIT2
ScrT3           VAR ScrB3.BIT3
ScrT4           VAR ScrB3.BIT4
ScrT5           VAR ScrB3.BIT5
ScrT6           VAR ScrB3.BIT6
ScrT7           VAR ScrB3.BIT7

Moves           VAR ScrB0

MoveRight       VAR ScrB0
MoveLeft        VAR ScrB1
MoveTime        VAR ScrB2

CoinFlip        VAR W2

Lights          VAR B6

RightLight      VAR B6
CenterLight     VAR B7
LeftLight       VAR B8

RefLights       VAR B9

RefRightLight   VAR B9
RefCenterLight  VAR B10
RefLeftLight    VAR B11

Counter0        VAR B12
Counter1        VAR B13
Counter2        VAR B14
Counter3        VAR B15
Counter4        VAR B16
Counter5        VAR B17

ResetCount      VAR B18.NIB0
Reserved0       VAR B18.NIB1
Reserved1       VAR B19
Reserved2       VAR B20

Motors          VAR B21

RightMotor      VAR B21
LeftMotor       VAR B22

LineCount       VAR B23.HIGHNIB
ObstacleCount   VAR B23.LOWNIB
StallCount      VAR B24.HIGHNIB

LeftLine        VAR B24.BIT3
RightLine       VAR B24.BIT2

LeftObstacle    VAR B24.BIT1
RightObstacle   VAR B24.BIT0

Flags           VAR B25

Flag_green      VAR Flags.BIT7
Flag_yellow     VAR Flags.BIT6
Flag_orange     VAR Flags.BIT5
Flag_red        VAR Flags.BIT4
Flag_magenta    VAR Flags.BIT3
Flag_purple     VAR Flags.BIT2
Flag_blue       VAR Flags.BIT1
Stalled         VAR Flags.BIT0

Tracy Allen

I hear you, that spans the ram. But I wonder about the implication that the compiler would somehow mess up the allocation. It seems to me that everything would come out exactly the same if it had used

VAR Word
or
VAR Byte

in each position where in the above it is assigned as,

VAR wN ' with N=0, 1, 2
or
VAR bN ' with N=6, .. ,25

All the assignments of aliases would remain exactly as they are. The end result would be exactly the same allocation by the compiler of names to the physical memory locations. I'm not saying there would be any advantage to doing it that way within that well thought out structure, just wondering about why you gave up on the compiler?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

It's not so much that it might mess it up, but that you can't see what it's doing or, in my case, see at a glance from the program source alone (i.e. without hitting CTRL-M) how much is left over. Granted, the allocation rule, "Assign from bigeest to smallest, and after that in order by appearance," is logical, consistent, and unlikely to change; but it's not part of the language's syntax. So programs that rely on it don't reveal that allocation explicitly (i.e. without one's considering the hidden rule). I just needed to be able to see what I was doing. In most cases, however, I don't really care how things are allocated, unless I'm bumping up against memory limits and having to share variables.

This is why — getting back to the original subject — I believe that array aliasing is important. An array, even though it's allocated by the compiler, imposes a visible substructure on its own portion of the memory. By aliasing variablea to array elements, I could see at a glance where, within that substructure these variables lie and how much of that structure is shared. Plus, as we've seen, if the array already exists for another purpose, trying to alias variables to it leads to awkwardness in PBASIC 2.5. It's a minor point perhaps, but the convenience seems far to outweigh any reasons for not doing it, which, from a solely technical standpoint, appear non-existent.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 8/10/2007 7:37:28 PM GMT