Bug with IDE compiler

PocketLint

I found, that with the following setup, the compiler generates an incorrect base address when using the @ operator in spin.

in a DAT section

MyByteDat byte 99

MyLongDat long $12345678


in spin

MyPtr·:= @MyLongDat

MyPtr will be three bytes off the real address of MylongDat.

I know the reason is because the system padded out the byte block to a long so that MyLongDat could be long aligned but I would have thought the compiler/IDE would know about this and report the correct address for MyLongDat

I have to put a dummy LONG before the MyLongDat label.



MyByteDat byte 99
long
MyLongDat long $12345678



Thanks,
Bob

Paul Baker

It's not an error of the compiler, you haven't observed the proper boundries. Longs must have thier two last bits of the address set to zero. This is handled automatically if the variables are declared in VAR, but you must handle this padding yourself if you declare stuff in the DAT. The need to observe boundries is covered in the manual.

The way the variable space handles packing is to declare all longs, then words, then bytes then pad the last location so that following code lies on a LONG boundry.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 8/23/2007 10:50:47 PM GMT

Mike Green

Part of your problem is that labels are defined before the opcode is evaluated and labels, in a DAT section, are really byte aligned since they can be used from Spin as well as assembly.· The compiler doesn't know that the data is long-aligned (or word-aligned for that matter) until after it processes the label.· It would be nice and helpful for the compiler to put out a warning if it encountered this situation, but there are no provisions for warning messages.· All errors terminate compilation.
·

PocketLint

Yeah, after I posted this I remembered seeing something about this and I just foundit.



Still, it would seem to me that using @label sould always return the correct address when using it at run time.



Thanks!

-Bob

deSilva

I never encountered that problem (And I have dug deeply!) I am also surprised by Paul's and Mike's answers as they make no sense to me from my current state of knowledge. The compiler should be absolutely able to know the RELATIVE offsets of any label during it's first phase...
I post this test program, which shows no issues of the kind discussed...

CON

  _clkmode = xtal1 + pll8x
  _xinfreq = 10_000_000

OBJ
  pc  :   "PC_Interface"  ' Aribas PropTrminal
  
VAR
  long   maxClk
  
PUB Main | mPos


  pc.start(31,30)

  repeat
    waitcnt(clkfreq+cnt)
    setpos(0,0) 
    pc.str(string("@a"))
    pc.hex(@a,4)
    setpos(0,1) 
    pc.str(string("@b"))
    pc.hex(@b,4)
    setpos(0,2)
    pc.str(string("@c"))
    pc.hex(@c,4)   

    
DAT
  a long $AAAAAAAA
  b byte "B"
  c long $CCCCCCCC

PRI setpos(px, py)

  pc.out(10)
  pc.out(px)
  pc.out(11)
  pc.out(py)

N.B.: DAT is allocated at the start of the memory, before the mas of code...

Post Edited (deSilva) : 8/24/2007 10:17:00 AM GMT

deSilva

A further Edit:

The Compiler cannot know the value of a RES label in it's first pass; the reason beeing the length of the defined area can be an arbitrary constant, thus recursion is possible, example:

DAT
  a LONG 0
  b LONG 0
  c RES (@b-@a)/4
  d RES 0

For this reason it is not allowed to evaluate the address of a RES label as a constant! Example

DAT
  a LONG @b  ' correct
  b LONG @d  ' error 
  c RES (@b-@a)/4
  d RES 0

Post Edited (deSilva) : 8/24/2007 10:53:55 AM GMT