Undefined object name symbol

[dbetz]

I just tried switching from BSTC to OpenSpin for compiling the Spin portions of xbasic and am running into a problem. I get an "undefined symbol 'vm'" error when compiling this code:

CON

  ' make some vm_interface constants available
  _MBOX_SIZE = vm#_MBOX_SIZE
  _STATE_SIZE = vm#_STATE_SIZE
  FLASH_BASE = vm#FLASH_BASE
  RAM_BASE = vm#RAM_BASE
  HUB_BASE = vm#HUB_BASE

  ' character codes
  CR = $0d
  LF = $0a

OBJ
  ser : "FullDuplexSerial"
  vm : "vm_interface"

PUB init_serial(baudrate, rxpin, txpin)
  ser.start(rxpin, txpin, 0, baudrate)

PUB init(mbox, state, code, data, cache_mbox, cache_line_mask) | params[vm#_INIT_SIZE]
  params[vm#INIT_BASE] := data
  params[vm#INIT_STATE] := state
  params[vm#INIT_MBOX] := mbox
  params[vm#INIT_CACHE_MBOX] := cache_mbox
  params[vm#INIT_CACHE_MASK] := cache_line_mask
  vm.start(code, @params)

Here is the error message:

Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2016 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.80 Compiled on Sep 29 2016 10:35:12
Compiling...
spin/serial_helper.spin
|-packet_driver.spin
|-vm_runtime.spin
vm_runtime.spin(21:73) : error : Undefined symbol
Line:
PUB init(mbox, state, code, data, cache_mbox, cache_line_mask) | params[vm#_INIT_SIZE]
Offending Item: vm

I built OpenSpin from sources cloned today from github so it should be the latest version.

[reltham]

As discussed in the forum posting, this is not a bug in OpenSpin. It's a limitation of the original compiler, but BSTC is allowing the code to work.

[dbetz]

Any chance it could be fixed in both? I guess you said it was a lot of work though. Anyway, it seems like a major flaw since it prevents symbols from an object to be used in a general way in an enclosing object.

On Oct 3, 2016, at 3:50 PM, Roy Eltham notifications@github.com wrote:

As discussed in the forum posting, this is not a bug in OpenSpin. It's a limitation of the original compiler, but BSTC is allowing the code to work.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #30 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1gXVNpnACg-sb2vgjuC6q7V7SmGAks5qwVyMgaJpZM4KKF2o.

[reltham]

Doubtful the original x86 compiler will be changed to allow this case. It's possible a future version of OpenSpin might be able to make this case work.

The total size of the local variables needs to be known during the first pass compile step, and during that step the symbols for any child objects are not known (the child objects haven't been compiled yet).

I would like to try some experiments reorganizing how the compiling is done. One possible solution is to add another pass up front that finds the entire object tree structure. Then compile everything starting with all the leaves first and then working back towards the root/top object. This could not only solve this issue, but would make the unused method removal simpler and less fragile. However, the end result compiled objects would likely not be 100% binary matches with the original compiler's output, since the order of compiling impacts some tables, offsets, etc. that are in the binary output. I'll have to try it and see.

[dbetz]

Hi Roy,

There is no rush to fix this design issue since I only found it trying to compile my old xbasic VM that no one is currently using. Your approach sounds like it would probably work though. in fact, xbasic has some similar problems and I think I handled it there by making an extra pass over the source where I only parse constants and function prototypes. That would fix this problem without a huge restructuring of the compiler. You only really need to capture the “interface” on this first pass. Anyway, thanks for considering my suggestion. You’ve done great work with OpenSpin!

David

On Oct 3, 2016, at 4:08 PM, Roy Eltham notifications@github.com wrote:

Doubtful the original x86 compiler will be changed to allow this case. It's possible a future version of OpenSpin might be able to make this case work.

The total size of the local variables needs to be known during the first pass compile step, and during that step the symbols for any child objects are not known (the child objects haven't been compiled yet).

I would like to try some experiments reorganizing how the compiling is done. One possible solution is to add another pass up front that finds the entire object tree structure. Then compile everything starting with all the leaves first and then working back towards the root/top object. This could not only solve this issue, but would make the unused method removal simpler and less fragile. However, the end result compiled objects would likely not be 100% binary matches with the original compiler's output, since the order of compiling impacts some tables, offsets, etc. that are in the binary output. I'll have to try it and see.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #30 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1oJ34H0fDxZyqDqJ2cCq5JcLlbubks5qwWDQgaJpZM4KKF2o.