Error message from OpenSpin

David Betz · 2016-09-29 14:32

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:

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

Any idea what's going wrong?

Roy Eltham · 2016-09-29 23:07

Can you try it with the preprocessor turned off?

David Betz · 2016-09-29 23:31

Roy Eltham wrote: »

Can you try it with the preprocessor turned off?

Not easily since I use preprocessor commands in my code. I can push the code to github so you can try it yourself.

https://github.com/dbetz/xbasic

If you get it from github you should be able to build it with these commands:

cd spin
openspin -o serial_helper.binary serial_helper.spin

Roy Eltham · 2016-09-29 23:42

Can you compile vm_runtime.spin itself? Looks like that doesn't use preprocessor stuff.
Also, can that compile in PropTool? (just vm_runtime.spin and it's dependencies)

I am currently at work, so I can't check/test anything until later tonight.

But as a note, OpenSpin is not BSTC compatible, it's designed to be compatible with Chip's original compiler, but with extensions. BSTC has stuff that is not supported by OpenSpin. Not saying there isn't a possible bug in OpenSpin here, but if you used BSTC extensions then it probably won't work in OpenSpin.

David Betz · 2016-09-29 23:45

Roy Eltham wrote: »

Can you compile vm_runtime.spin itself? Looks like that doesn't use preprocessor stuff.
Also, can that compile in PropTool? (just vm_runtime.spin and it's dependencies)

I am currently at work, so I can't check/test anything until later tonight.

But as a note, OpenSpin is not BSTC compatible, it's designed to be compatible with Chip's original compiler, but with extensions. BSTC has stuff that is not supported by OpenSpin. Not saying there isn't a possible bug in OpenSpin here, but if you used BSTC extensions then it probably won't work in OpenSpin.

Is the # syntax a BST extension? Anyway, I tried just compiling vm_runtime.spin with -p and got the same error.

Roy Eltham · 2016-09-30 00:28

No, the # syntax (to access CON items from a child object) itself is not an extension, but the context (inside the array brackets of a local var declaration) might not be handled in PropTool and/or OpenSpin.

Can you try vm_runtime.spin in PropTool?

Dave Hein · 2016-09-30 01:01

I tried a small test program in the PropTool, and it had the same problem that David encountered with OpenSpin. It worked fine with BSTC.

David Betz · 2016-09-30 02:06

Dave Hein wrote: »

I tried a small test program in the PropTool, and it had the same problem that David encountered with OpenSpin. It worked fine with BSTC.

I tried defining a CON whose value was the # expression and using that inside of the brackets and that didn't work either. Is it not possible to use a CON as the size of a local array?

In other words, I did this:

CON
    _INIT_SIZE = vm#_INIT_SIZE

Roy Eltham · 2016-09-30 02:16

I tested compiling vm_runtime.spin in PropTool and it fails in the same way that OpenSpin does. So the official compiler doesn't support using a constant from another object as the size of a local array variable.

This is because during the first pass compile step the sub objects are not compiled yet, so it doesn't have the value defined, and in this case, the local variable information is required to be fully defined in the first pass because the size of the local variables is part of the Symbol information that is created during the first pass.

So this is a case where BSTC is allow something not normally allowed. I looked over the code in OpenSpin, and it would be a significant rework of the compile passes to make this work out.

An alternate solution for your case would be to change the CON section of vm_interface.spin to be an #include file and then use the CON values directly in vm_runtime.spin without the vm# prefix.

David Betz · 2016-09-30 02:32

Roy Eltham wrote: »

I tested compiling vm_runtime.spin in PropTool and it fails in the same way that OpenSpin does. So the official compiler doesn't support using a constant from another object as the size of a local array variable.

This is because during the first pass compile step the sub objects are not compiled yet, so it doesn't have the value defined, and in this case, the local variable information is required to be fully defined in the first pass because the size of the local variables is part of the Symbol information that is created during the first pass.

So this is a case where BSTC is allow something not normally allowed. I looked over the code in OpenSpin, and it would be a significant rework of the compile passes to make this work out.

An alternate solution for your case would be to change the CON section of vm_interface.spin to be an #include file and then use the CON values directly in vm_runtime.spin without the vm# prefix.

Okay, I'll try that. This does seem like a bug though even though the same bug is in the Propeller Tool. Thanks for suggesting a workaround!

Roy Eltham · 2016-09-30 02:40

It's more of a design flaw in the compiler than a bug.

If things were reworked to walk all the way down to the leaf child objects to compile them first before trying to first pass compile any parent objects then it could fix this situation, but that is a significant rework. It's possible we might want to do this as part of implementing Spin2. It'll be up to Chip and Jeff.

David Betz · 2016-09-30 02:46

Roy Eltham wrote: »

It's more of a design flaw in the compiler than a bug.

If things were reworked to walk all the way down to the leaf child objects to compile them first before trying to first pass compile any parent objects then it could fix this situation, but that is a significant rework. It's possible we might want to do this as part of implementing Spin2. It'll be up to Chip and Jeff.

I really wish Chip would consider writing the official Spin2 compiler in a high-level language and not in x86 assembler. It would even make it easier to port to the P2 itself since one of his goals is a self-hosted system. Why write the Spin2 compiler twice to achieve that. There is really no reason to write tools in assembler these days.

Roy Eltham · 2016-09-30 03:32

Well, there was some discussion of us (me Chip and Jeff) working together to make the P2 stuff in the OpenSpin framework.

Chip has got pnut doing all the P2ASM stuff using x86 code evolved from what he had for P1 (that was what I ported to make OpenSpin). So it should be easier to being over his new stuff than it was to do initially.
I know Ken has said in the past that he would like to have the equivalent of OpenSpin for P2 ready at launch of the P2. Not sure if that's still what he wants. I would like it to happen.

The main issue will be time. P2 needs to be done and out ASAP as far as Ken is concerned, and Chip might feel that he can get Spin2 done faster just doing it all in x86 as he has done so far. So there might not be enough time to have OpenSpin2 done in time if Chip does the same x86 thing for everything and I have to port it afterwards. At least it will be done sooner after launch than the P1 version...

I'll be visiting Parallax soon to talk with Jeff and hopefully Ken (if he's not travelling at the time). I'll be visiting Chip at the same time, so some of this will be discussed.

jmg · 2016-09-30 03:40

David Betz wrote: »

I really wish Chip would consider writing the official Spin2 compiler in a high-level language and not in x86 assembler. It would even make it easier to port to the P2 itself since one of his goals is a self-hosted system. Why write the Spin2 compiler twice to achieve that. There is really no reason to write tools in assembler these days.

Yes, it certainly is best to avoid x86 assembler these days..

There is some P2 Spin already working in this thread, that targets both P1 and P2, sounds ideal for P2 development.

http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2

David Betz · 2016-09-30 06:22

jmg wrote: »

David Betz wrote: »

I really wish Chip would consider writing the official Spin2 compiler in a high-level language and not in x86 assembler. It would even make it easier to port to the P2 itself since one of his goals is a self-hosted system. Why write the Spin2 compiler twice to achieve that. There is really no reason to write tools in assembler these days.

Yes, it certainly is best to avoid x86 assembler these days..

There is some P2 Spin already working in this thread, that targets both P1 and P2, sounds ideal for P2 development.

http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2

Yes, Eric has done some nice work with FastSpin.

Error message from OpenSpin

Comments