Propeller Tool Limits

RogerInHawaii

The Propeller Tool has a couple of limits that I've recently encountered:

·· 1. Variable names (as well as method names, constant names, etc) are limited to a maximum of 30 characters each

·· 2. The number of parameters that a method may have is limited to 15

These seem like the kinds of limitations that one would have imposed back in the early days of programming languages when every byte of memory or disk space was at a·premium. That has not been the case for decades.

I have situations where it would be very helpful to NOT have such limits. Are there valid reasons for these limitations? Is there any way to overcome these limitations?

Phil Pilgrim (PhiPi)

Roger,

The first question that comes to my mind is why on earth would you ever want even 30-character variable names or 15 method parameters? Variable names even half that long will disrupt a program's readability by stretching math expressions to enormous lengths. And too many parameters in a method call also make a program difficult to follow. (Let's see: is positionX parameter 9 or parameter 10? Okay: 1, 2, 3, 4, 5, ... oh, right, it's 8.) In the latter case, a pointer to an array is probably the better choice. That way you can fill the parameter list using named constants as indices, viz:

param[noparse][[/noparse]XPOS] := x
param[noparse][[/noparse]YPOS] := y
param[noparse][[/noparse]TIME] := cnt
k := MyMethod(@param)

-Phil

RogerInHawaii

For the same reason that programmers like to have more than 8 characters for file names and 3 characters for file extensions. There simply are indeed situations where it is useful and actually does make the program more readable.

As for using arrays with "named" subscripts as a means of passing values to a method, that's more of a way around the limitation than a means of making the program more readable.·I'll acknowledge that in this very simple, non-typed programming language it does make it difficult to make sure that the parameters "line up".

Phil Pilgrim (PhiPi)

"Positional parameter association" is one of my pet peeves with most programming languages. After three or four parameters, it becomes difficult to keep track of which parameter goes with which argument (or vice-versa). Languages that support hashes (e.g. Perl) provide a mechanism for creating named parameter associations, but such would be a bit much to expect for Spin, and the overhead would be excessive. I think the best approach is to embrace the language for what it is and try to work within its limitations. I mean, all in all, Spin really is pretty sweet, don't you think?

-Phil

RogerInHawaii

Phil Pilgrim (PhiPi) said...
"Positional parameter association" is one of my pet peeves with most programming languages. After three or four parameters, it becomes difficult to keep track of which parameter goes with which argument (or vice-versa). Languages that support hashes (e.g. Perl) provide a mechanism for creating named parameter associations, but such would be a bit much to expect for Spin, and the overhead would be excessive. I think the best approach is to embrace the language for what it is and try to work within its limitations. I mean, all in all, Spin really is pretty sweet, don't you think?

-Phil

I absolutely agree that Spin is "sweet" and I'm quite grateful that both the Spin language and the Propeller chips exist. As for the variable name length and parameter count limitations,·I'm sure there's just a definition somewhere in the implementation where they decided, hey, let's make it 30 characters max for names and 15 parameters max for parameters. And those could probably quite easily be increased.

As for positional parameter association, I worked on the Ada programming language many, many·years ago, and as I recall·it allowed you to specify the names of the parameters when you called·a method, so ordering didn't much matter.

For example, if you had a method defined like this:

··· MyMethod(int Fred, int Mary, int Joe)

you could call it like this:

·· MyMethod(Joe = 13, Mary = 7, 6)

The 6 would end up in Fred, since it was the only one left.
·

MagIO2

The limit in variable name length is of course a compiler only limitation and I can't see a reason for that either - even if I don't miss longer names.

But the limit of 15 parameters in my opinion is not to bad and if you need more you do something wrong! You should keep in mind that the propeller is a microcontroller with very limited resources. Why would there be a need to put variables from variable-space to stack-space? You have doubled the need of resources (memory) and you increase runtime. Besides that it might be a interpreter limitation. Maybe in the bytecode there is only room for 4bit stack-relative adresses, which is 15 parameters plus return value = 16.

Mike Green

Having non-positional (named) parameters in a subroutine call is much more complicated than simply having positional parameters. With positional parameters, the compiler simply generates code to evaluate some fixed number of expressions and these are left on the stack when the subroutine is called. The names of the various parameters don't even have to be known at the point of call.

I can't say whether the length of variable names is a named constant in the compiler code. Keep in mind that the Parallax Spin compiler is written in assembly language for Windows, so it's probably not as flexible as you might think. The two 3rd party Spin compilers (BradC's and mpark's) should be much more flexible.

Phil Pilgrim (PhiPi)

Not to suggest that's it's any kind of priority, but the following could be done without any changes to the byte-code interpreter:

PUB SerialStart(RcvPin : 31, XmtPin : 30, BaudRate : 9600)
...

where the values after the colon are the defaults when the named argument is omitted from the call. Such a method could be called in the standard way:

sio.SerialStart(31, 30, 4800)

or using named arguments:

sio.SerialStart(BaudRate : 4800)

In the latter case, the compiler would simply generate the same positional code as in the former case, filling in the default values for arguments that are absent. Mixing positional and named arguments would lead to ambiguities, though, and should not be allowed.

-Phil

WNed

RogerIn Hawaii said...
These seem like the kinds of limitations that one would have imposed back in the early days of programming languages when every byte of memory or disk space was at a premium. That has not been the case for decades.

I was going to carry on about the differences in paradigm between general purpose microprocessors and embedded microcontrollers, and the various uses, requirements, and limitations then I remembered, every day I deal with some of the same stone age limitations you are complaining about. My platform (the one I get paid for)? The IBM iSeries mid-range computer.

Chain saw
Hack saw
Which is a better saw?

Ned

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno

Duffer

Ned,

It's hard to see which saw you need, until you see it as the saw sees the need.

Duffer

WNed

A chain saw is a horrible saw for *any* application, if you don't know how to start it...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno

Beanie2k

WNed said...
A chain saw is a horrible saw for *any* application, if you don't know how to start it...

You mean it has a motor??? Gee no wonder it took me so long to cut that tree down!!

Jeff Martin

MagIO2 said...
The limit in variable name length is of course a compiler only limitation and I can't see a reason for that either - even if I don't miss longer names.

But the limit of 15 parameters in my opinion is not to bad and if you need more you do something wrong! You should keep in mind that the propeller is a microcontroller with very limited resources. Why would there be a need to put variables from variable-space to stack-space? You have doubled the need of resources (memory) and you increase runtime. Besides that it might be a interpreter limitation. Maybe in the bytecode there is only room for 4bit stack-relative adresses, which is 15 parameters plus return value = 16.

MagIO2 is right.

To be more specific, the limit in variable name length is a practical limit that helps keep the symbol table size from getting out of hand in the compiler.· We don't think there's enough reason for variable names greater than that size which outweighs the negative memory footprint effects it has on the compiler's run-time usage for every program that does not have such long variable names.· We feel that around 30 characters is a good practical limit.· I remember being limited to 2 character variable names when I first started programming... anything over 8 is wonderful to me... anything approaching 30 characters is way to long.· I know this topic is fodder for much debate as "memory" on the PC is virtually endless these days, but the overall goal of ours is to put the development tools in the Propeller chip itself (something we wanted to do with Propeller 1 but there just wasn't enough resources in that version to make it practical).· The Propeller 2 will likely have some development tools built-in (but of course we'll enhance the Propeller Tool to support it as well).

The limit of 15 parameters a chip-based and interpreter based.· Each parameter is stored on the stack, along with the return variable and other local variables.· Again, it was a "practical" design decision meant to be sufficiently high for most, if not all, applications, and not just one for run-time use, but also a practical limit to help guide people into coding efficiently on a microcontroller.·

While the variable limit size could change (in the compiler), and the parameter list size could change in the next Propeller chip, they are both unlikely to be changed unless we find an overwhelmingly compelling need for it.

Take care,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.