openspin bug?

David Betz

I'm trying to build some old code with openspin and I'm having trouble with code that uses CON values from another object. Is this supported in openspin?
This is the code in my vm_interface.spin module:

CON

INIT_BASE         = 0
INIT_STATE        = 1
INIT_MBOX         = 2
INIT_CACHE_MBOX   = 3
INIT_CACHE_MASK   = 4
_INIT_SIZE        = 5

And this is the reference in the including object:

OBJ
  vm : "vm_interface"

PUB init(mbox, state, code, data, cache_mbox, cache_line_mask) | params[vm#_INIT_SIZE]

Here is the error I get:

vm_runtime.spin(16:73) : error : Undefined symbol
Line:
PUB init(mbox, state, code, data, cache_mbox, cache_line_mask) | params[vm#_INIT_SIZE]
Offending Item: vm

Shouldn't this work?

Phil Pilgrim (PhiPi)

It's not a bug. It's just a consequence of the limited number of passes the compiler makes. When memory is being allocated for your local variable, vm#_INIT_SIZE is not yet known. The same error occurs in Propeller Tool.

-Phil

David Betz

Phil Pilgrim (PhiPi) wrote: »

It's not a bug. It's just a consequence of the limited number of passes the compiler makes. When memory is being allocated for your local variable, vm#_INIT_SIZE is not yet known. The same error occurs in Propeller Tool.

-Phil

That's quite odd because it is a CON in the included object. It's value can be known on the very first pass. Seems like a bug to me. In any case, how would you handle this? I want the outer object to allocate an array to pass to the inner object but I don't want to hardcode the array size. It should be part of the interface to the vm_runtime object.

Phil Pilgrim (PhiPi)

Use a global variable instead. That works in Propeller Tool.

-Phil

David Betz

Phil Pilgrim (PhiPi) wrote: »

Use a global variable instead. That works in Propeller Tool.

-Phil

That works but is wasteful of hub space. Is there any plan to fix this bug? I realize that it is a bug in both the Propeller Tool and OpenSpin but that isn't really surprising since OpenSpin is pretty much a direct translation of the code in Propeller Tool. And please don't say this is "a feature not a bug".

Dave Hein

There are a few limitations of the Spin compiler that are not well documented. It wasn't clear to my how the Spin compiler handles forward references in the CON section until I tested it. The following code works

CON
  CON1 = CON2
  CON2 = 0

but this code fails

CON
  CON1 = CON2
  CON2 = CON3
  CON3 = 0

In p2asm I implemented this by doing up to 2 passes of the CON sections. Deeper forward references could be implemented by doing more passes, but I chose to mimic the same limitations as the Prop Tool and PNut.

I have to admit that it seems odd that you can't use vm#_INIT_SIZE to declare a local variable array, but can use it in VAR and DAT sections. I thought maybe you could define a local CON value equal to vm#_INIT_SIZE, and use that for the array, but that doesn't work either. Is it a bug, or just an undocumented limitation of the compiler? There is no formal definition for the Spin language, so I don't think you can call it a bug. In lieu of a formal definition, the compiler defines the language.

David Betz

It seems that the formal definition of Spin is whatever the Propeller Tool does. So I guess there can be no bugs in Spin by definition as long as it matches the Propeller Tool. It seems to me though that limitations like this should have been addressed over the long history of the Spin tools. Has there ever been an update to Spin since it was first released?

Dave Hein

Yes, the Prop tool has been updated a few times. The latest update is version 1.3.2 from about 6 years ago. OpenSpin does what the Prop tool does, except for maybe a few preprocessor commands. BST has a few more features, such as code optimization, but it hasn't been updated for many years.

Spin2 will introduce new features to the Spin language. Hopefully a new Spin2 compiler will support the P1 as well. After all, the new features proposed for Spin2 could have been implemented on the P1 years ago.

David Betz

Dave Hein wrote: »

Yes, the Prop tool has been updated a few times. The latest update is version 1.3.2 from about 6 years ago. OpenSpin does what the Prop tool does, except for maybe a few preprocessor commands. BST has a few more features, such as code optimization, but it hasn't been update for many years.

FYI, BST does not have this bug.

Phil Pilgrim (PhiPi)

David Betz wrote:

That works but is wasteful of hub space.

Oh, come on! We're talking about five longs here. But that statement may not even be correct. After a certain small size limit, the byte codes required to access the later variables in the local stack get longer. As a consequence, I would almost never declare a local array.

I would also be reluctant to use a feature in BST or any other compiler that's not supported by PropTool. Should I decide to post the code here or contribute it to the OBEX, it would be very confusing for others who decide to use it.

David Betz

Phil Pilgrim (PhiPi) wrote: »

David Betz wrote:

That works but is wasteful of hub space.

Oh, come on! We're talking about five longs here. But that statement may not even be correct. After a certain small size limit, the byte codes required to access the later variables in the local stack get longer. As a consequence, I would almost never declare a local array.

I would also be reluctant to use a feature in BST or any other compiler that's not supported by PropTool. Should I decide to post the code here or contribute it to the OBEX, it would be very confusing for others who decide to use it.

You may think it is silly but this is a bug. I suppose it isn't a very serious one since no one seems to have reported it before but the compiler really should handle this.