Be nice if you could initialize vars in a var section...
Rayman
Posts: 14,744
in Propeller 2
Just thinking it would be nice to be able to do something like this:
var long calibration[8]= 0,0,0,-5,0,0,0,5
Comments
You can do it in DAT
...and get the same effect.
You could copy that DAT data to VARs, so that each object instance would have its own unique copy to modify.
I think so, too. Then vars for every instance of an object could be conveniently initialized at the "point of origin."
As I understand Spin, it is not fully dynamic. Meaning, you can't create Objects on the fly for example with a new operator. This means, that the memory for the vars of each object is already "reserved" at compile-time. So, actually the demanded variable initialization would only be a compiler job. This would in the end be saving a DAT block, which stores the initial values, and the runtime of the copy-job.
However, it looks like it is not as simple as it sounds. Problem is, that you then have to increase the binary size, as variables are currently not part of the file sent to the propeller. How do you want to handle mixed vars, some initialized, some not, taking into account that the vars come at the end of the binary and are sorted per object? Either you have to add a lot of zero-values to the file, or you have to change the sorting and have 2 var-pointers, one pointing to the initialized vars and one to the not initialized vars.
I think as long as nobody runs out of memory, the bytemove from dat to var is the best compromise.
Yes, this is one line of code and it takes care of the problem. Otherwise, we have the initialization nightmare detailed above.
Is the binary size really a problem? I've loaded some big ones and it's very fast...
Don't see an issue with sending over a bunch of zeros...
I work hard to keep everything as small as possible. Actually, the compiler could build a run-length-compressed table and use it to initialize the VAR variables. That might be an efficient way to do this.
Binary size is always a problem.
Revisit this discussion some months from now and people will ask where that extra Kb of data came from.
It also might be useful to have constant arrays like this:
But, I guess that would be more difficult to do...
Ultimately, such data has to come from a table, somewhere. Wouldn't it better to just have the table unambiguously declared in a DAT section?
Yes, of course. The Spin DAT section is a really great feature. Not as pretty as CON or VAR though...
It's just that I've been coding in C recently and when I came back to Spin2 to get something started I noticed these things that seemed to be unnecessarily limiting...
I ran into this the other day, trying to write code more complex than overflow speed testing. It seemed like a good idea to try - but it did not work well at all. I then tried putting them in the DAT section, but that didn't seem to work either - until I realized that all my horrible errors were from naming the file whatever.spin not .spin2. The Propellor Software Tool is VERY sensitive to file extensions!! S.
ETA: I finally said "heck with it" and initialized them in pub main(). That worked.
You probably know this, but you can have as many DAT sections as you want. You could locate one just above or below your PUB/PRI method that uses it.
Up to the variable limit, one presumes.
S.
The DAT sections are great, but that's pretty much where I put all the ugly stuff in a code. And, usually put it at the very bottom of the file, out of the way.
I have put DAT sections near the top before. It works, but it's not pretty...
I don't understand the reasoning for making Spin2 look more like C or C++. Why not just program in C or C++ if that's what you want. I think Spin2 has lost the simplicity of Spin that made it a great learning language. Also, there are so many arbitrary differences between Spin2 and Spin that it makes it a pain to port Spin programs. It would have been nice if Spin2 would have been designed so that Spin was a subset of it.
I don't know what you mean with extra kbyte. The VAR section does not make it into the binary, but still it uses HUB RAM. If your VAR section becomes too big, you can't compile the code.
In fact , I think the problem with binary size only materializes, if you want to put different binaries onto some device which has a limited size - like an EEPROM for example. And maybe it was more important for Propeller 1?
The implementation of initialized variables is only difficult, if you keep saying that you want to optimize for size. In case you don't care about size, you could also run an all or nothing strategy, which keeps compiler implementation easy. Either all variables are initialized, or none at all. The second case would result in the same binaries that we have now, the first case would result in a binary size which exactly matches with the HUB-RAM needed by the program (code + dat + var).
Constant array is a funny thing I would say. Constants are there to give numbers spread all over the code a meaningful name, so that the code is more readable. And you have a central place for changes that you'd have to do in different places of the code otherwise.
A constant array would contradict the readability, because VGA_MODE[0] would again be worse than VGA_MODE_80x40 ... for example.
And developers have to understand that a constant array can not be used with a variable as an index ( VGA_MODE[i] ). Constants are code constructs which are relevant during compile-time. Constants not used in the code would not be part of the binary. Using a variable index with constants would mean that all constants need to be added to the binary and in fact such a constant would have to become a part of a DAT section then.
Having initialized variables would actually save memory, because instead of needing memory for the VAR itself, the DAT to initialize it with and the code to do the initialization, just the VAR is needed. Just trim the binary at the last non-zero byte and the binary size increase is mostly gone, too. The flash loader is two-stage, anyways, so when flash space really is at a premium (which it isn't, with the current hardware having 16M flashes), the binary could be stored in a compressed format.
Are you sure? What do you initialize your screen buffers with? ;o)
Qhat do you mean?
Initializing only saves memory if you use a DAT for storing the init-values and some spin copying those into the VAR memory. But a lot of VARs are used for example for screen buffers or transfer buffers or for the stack. Those don't need initialization, so no DAT and no initialization code, nothing to save there.
VARs are sorted per object to keep the object variables together. So, if the last object uses initialized variables, all the zero-value-vars need to be stored in the binary. So, no savings there either.
A different sorting means a lot of work to rewrite the compiler and the interpreter.
It saves runtime memory is what I meant. Obviously the binary becomes larger under certain circumstances, but as I said, if binary size was a concern, compressing it would make it a lot smaller, anyways.