openspin bug?

David BetzDavid Betz Posts: 13,122
edited 2018-08-23 - 02:35:08 in Propeller 1
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?

Comments

  • 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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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.

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

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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".
  • 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.
  • 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 HeinDave Hein Posts: 5,834
    edited 2018-08-23 - 13:17:03
    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.
  • 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.

  • 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.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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.
Sign In or Register to comment.