BST Bug

Dave Hein · 2013-11-15 12:29

I came across a BST bug that took me a while to track down. It appears that BST allows local stack variables to have the same name as a global variable. The code shown below compiles under BST, but the Prop Tool will display a compile error. It would actually be a nice feature if BST used the stack variable within the method, but it ignores the stack variable and uses the global variable instead.

CON
  _clkmode = xtal1 + pll16x
  _clkfreq = 80_000_000

OBJ
  ser : "FullDuplexSerial"

DAT
  val long 1

PUB main
  ser.start(31, 30, 0, 115_200)
  waitcnt(clkfreq*3+cnt)
  test1(2)
  waitcnt(clkfreq/10+cnt)

PUB test1(val)
  ser.dec(val)

dgately · 2013-11-15 12:49

OpenSpin thinks it is an error too!

Project Directory: /Users/altergator/Documents/

openspin -I /Users/altergator/ParallaxCode/SpinObjects/ test.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled for Catalina on Sep 10 2013
Compiling...
test.spin
|-FullDuplexSerialPlus.spin
test.spin(17:11) : error : Expected a unique parameter name
Line:
PUB test1(val)
Offending Item: val

Since OpenSpin is "the future" for spin code compiling in IDEs 'like' SimpleIDE, I don't think there's going to be any fix, especially since BST (with its compiler, "bstc") is no longer getting any support.

dgately

Tracy Allen · 2013-11-15 14:52

That's funny, tried it, it did throw an error:

Screen shot 2013-11-15 at 2.50.04 PM.png

bst 0.19.5
compiler 0.15.4 pre5

Dave Hein · 2013-11-15 15:02

I'm using bstc 0.15.3, so it must have been fixed in 0.15.4.

David Betz · 2013-11-15 15:48

Dave Hein wrote: »
I came across a BST bug that took me a while to track down. It appears that BST allows local stack variables to have the same name as a global variable. The code shown below compiles under BST, but the Prop Tool will display a compile error. It would actually be a nice feature if BST used the stack variable within the method, but it ignores the stack variable and uses the global variable instead.
CON
  _clkmode = xtal1 + pll16x
  _clkfreq = 80_000_000

OBJ
  ser : "FullDuplexSerial"

DAT
  val long 1

PUB main
  ser.start(31, 30, 0, 115_200)
  waitcnt(clkfreq*3+cnt)
  test1(2)
  waitcnt(clkfreq/10+cnt)

PUB test1(val)
  ser.dec(val)

I thought this was true of the Propeller Tool as well.

Dave Hein · 2013-11-15 17:59

My OP may have been a bit confusing. The correct thing for the compiler to do is to throw a compile error when a local variable has the same name as a global variable. The Spin Tool, OpenSpin and the later version of BST do the right thing. BSTC 0.15.3 does the wrong thing, and compiles it without throwing an error. I just happens that this version is the one distributed with PropGCC.

David Betz · 2013-11-15 18:10

Dave Hein wrote: »

My OP may have been a bit confusing. The correct thing for the compiler to do is to throw a compile error when a local variable has the same name as a global variable. The Spin Tool, OpenSpin and the later version of BST do the right thing. BSTC 0.15.3 does the wrong thing, and compiles it without throwing an error. I just happens that this version is the one distributed with PropGCC.

I found it very annoying that the Spin tool behaved this way. It is contrary to the way any other language I've ever used has behaved. It means you can't just copy a function from one module to another with potentially having to rename function parameters and/or local variables.

Phil Pilgrim (PhiPi) · 2013-11-15 19:29

David Betz wrote:

I found it very annoying that the Spin tool behaved this way.

The Propeller Tool does not use a dictionary stack, which is required for the "correct" behavior. But I'm willing to give Chip a bye on this one. Hopefully, future versions of the Spin compiler will support local variable scoping. I would also like to see automatic case-correction (i.e. usage case corrected to defined case) -- but not case sensitivity -- in Spin.

-Phil

David Betz · 2013-11-16 05:50

Dave Hein wrote: »

My OP may have been a bit confusing. The correct thing for the compiler to do is to throw a compile error when a local variable has the same name as a global variable. The Spin Tool, OpenSpin and the later version of BST do the right thing. BSTC 0.15.3 does the wrong thing, and compiles it without throwing an error. I just happens that this version is the one distributed with PropGCC.

FYI, bstc will not be included at all in future releases of propgcc. The release_1_0 and default branches both now use openspin and I'm hoping to remove the small amount of remaining Spin code from the default branch before we release it.

Mark_T · 2013-11-16 06:20

Dave Hein wrote: »

My OP may have been a bit confusing. The correct thing for the compiler to do is to throw a compile error when a local variable has the same name as a global variable.

Totally disagree, local variables should never name clash, only shadow. Programming languages are just lambda-calculus after all.

David Betz · 2013-11-16 06:39

Mark_T wrote: »

Totally disagree, local variables should never name clash, only shadow. Programming languages are just lambda-calculus after all.

I suspect that this bug can probably be fixed in openspin and that is going to be the official Spin compiler from Parallax. It probably isn't worth trying to fix this in the Propeller Tool.

Heater. · 2013-11-16 07:13

David.

I suspect that this bug can probably be fixed in openspin.

Do we get a "this" or other means of namespace resolution then?

David Betz · 2013-11-16 09:01

Heater. wrote: »

David.

Do we get a "this" or other means of namespace resolution then?

I'm not sure why that would be necessary. In C a local variable or function argument shadows a global with the same name and there is no way to refer to the global in that function body.

Heater. · 2013-11-16 09:13

Perhaps not necessary but nice.

Spin is not C. It has objects, there are no global variables, there are instance variables.

It always annoys me having to dream up new names for things to get around these issues. I might have a parameter "length", say. because that is the most obvious name for it, then I might want an instance variable "length" because that is also the most obvious name for it.

I was reminded of this recently when I had to make changes to a big old program in Pascal. In Free Pascal I need a different name for each of:
a) Parameters to methods.
b) Instance variables.
c) Names of any properties I define for the class.
d) Probably globals/module variables as well.

That Pascal code is full of "warts", fields in a class are prefixed with "F" and so on. Makes an ugly mess.

David Betz · 2013-11-16 09:17

Heater. wrote: »

Perhaps not necessary but nice.

Spin is not C. It has objects, there are no global variables, there are instance variables.

It always annoys me having to dream up new names for things to get around these issues. I might have a parameter "length", say. because that is the most obvious name for it, then I might want an instance variable "length" because that is also the most obvious name for it.

I was reminded of this recently when I had to make changes to a big old program in Pascal. In Free Pascal I need a different name for each of:
a) Parameters to methods.
b) Instance variables.
c) Names of any properties I define for the class.
d) Probably globals/module variables as well.

That Pascal code is full of "warts", fields in a class are prefixed with "F" and so on. Makes an ugly mess.

I agree that it would be nice. I only meant it isn't absolutely necessary.

Dave Hein · 2013-11-16 17:02

Mark_T wrote: »

Totally disagree, local variables should never name clash, only shadow. Programming languages are just lambda-calculus after all.

If we want to redefine how Spin works, then local variables could shadow global variables. However, that's now how local variables are defined in the Prop manual.

LocalVar must be globally unique, but other methods may also use the same symbol name.

Like I said in the OP, it would be a "nice feature" if the global variable name could be used as a local variable within the scope of the method.

BST Bug

Comments