Suggestion: sizeof(<Identifier>) for Spin
Nick Mueller
Posts: 815
Hi!
I know it doesn't exist, so my request.
A sizeof($someIdentifier) for Spin would be very handy.
Say one wants to save a variable to EEPROM, knowing the size would help a lot. I could calculate it by hand, but then I do have a maintenance-problem (when my code changes). I also could arrange all vars in a sequence and put a sentinel behind the last one and use the difference in addresses to calculate the size, but then again: What when the code changes? What if I don't want to change the sequence? What if one var gets bigger and the other one smaller? What if for some reason the vars do get a new layout in RAM because of a new compiler version?
Other scenarios would be passing an array of varying length to a generic function (like build the average over a list of values).
The sizeof operator should return the size in bytes. Making it a compile-time-only feature is enough. sizeof should be able to handle this correctly:
The compiler does know the sizes, because he does make a layout for the RAM.
And how do I get that feature today?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I know it doesn't exist, so my request.
A sizeof($someIdentifier) for Spin would be very handy.
Say one wants to save a variable to EEPROM, knowing the size would help a lot. I could calculate it by hand, but then I do have a maintenance-problem (when my code changes). I also could arrange all vars in a sequence and put a sentinel behind the last one and use the difference in addresses to calculate the size, but then again: What when the code changes? What if I don't want to change the sequence? What if one var gets bigger and the other one smaller? What if for some reason the vars do get a new layout in RAM because of a new compiler version?
Other scenarios would be passing an array of varying length to a generic function (like build the average over a list of values).
The sizeof operator should return the size in bytes. Making it a compile-time-only feature is enough. sizeof should be able to handle this correctly:
VAR long SomeArray[noparse][[/noparse] 10 ] ... sizeof(SomeArray) 'returns 40 sizeof(SomeArray[noparse][[/noparse] 0 ]) 'returns 4
The compiler does know the sizes, because he does make a layout for the RAM.
And how do I get that feature today?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Comments
CON SomeArraySize = 10 LongSize = 4 VAR LONG SomeArray[noparse][[/noparse]SomeArraySize] ... constant(SomeArraySize*LongSize) 'returns 40 longsize ' returns 4▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
you have still the most fantastic ideas of how SPIN handles "DATA". SPIN does not handle "DATA". There is no such thing as an "ARRAY"....
SPN is a "structured assemply language"
Paraphrasing the Wikipedia entry for "Array": In Computer Science an array is a "data structure" consisting of a group of "elements" that are accessed by "indexing". In most programming languages each element has the same "data type" and the array occupies a contiguous area of storage. Most programming languages have a built-in array data type. Paraphrasing Wikipedia...
So, we have a zero terminated string made with:
string("123456). The data in the string is cf the same data type and occupies a contiguous area of storage. The string (arguably an array) is accessed by "indexing" with perhaps:
. To help in knowing the total array size when indexing the data within the array, Spin includes the likes of:
, where @stringaddress is the pointer to the location of the "array" in storage.
Hmmm...
Exactly this does *not* solve the maintenance problem.
With your background, you should know what that means.
Make a change in one place and *only* in one place. Your suggestion requires changes in at least two places. -> maintenance problem.
It's getting really funny with constructs like:
> you have still the most fantastic ideas of how SPIN handles "DATA". SPIN does not handle "DATA".
> There is no such thing as an "ARRAY"....
Oh my god! Spin does not reserve memory for a construct like "long someArray[noparse][[/noparse] 10 ]" and it does not handle indices?
I *REALLY* must have missed something.
Further I don't care -in this case- how Spind handles VARs, I only request a sizeof operator and I am 100% sure it could do it.
Maybe you only missed the "compile-time"?
Have a closer look:
a) "long someVar[noparse][[/noparse] 10 ]" reserves 10 longs in HUB-RAM
b) x:= someVar[noparse][[/noparse] 3 ] is aware of the type (the long), or the index would be wrong (byte? word?, long?)
c) even if someVar[noparse][[/noparse] $index ] is handled like a pointer, still b) is true
d) try a "long someHugeArray[noparse][[/noparse] 1000000 ]" to see that Spin *is* aware of how much memory the declaration consumes
e) I'll have to tear out several pages of the Propeller-Manual containing the word "array"
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
> (strsize(@stringaddress))
This only works for strings, because they are zero-terminated. It is a runtime-computation and not done at compile-time.
strsize is not aware of the length @stringaddress points to. Don't know a language that would do that for a *pointer*. And also wouldn't ask for it.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
1) Yes it does.
2) Yes I do, thanks.
3) Yes. Set one value in only one place.
4) No it does not.
...[noparse][[/noparse]something I did not suggest]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Possible workaround,
When you define a variable (may be an array) with name VARNAME,
then also define a constant with the name sizeofVARNAME.
(place the constant directly above the variable)
CON
· sizeofVARNAME = 40
VAR
· word VARNAME[noparse][[/noparse]20]
where you would like to use sizeof(VARNAME), use sizeofVARNAME
regards peter
It does not (see below)
> 3) Yes. Set one value in only one place.
And what if you change it from long to word?
> 4) No it does not.
It does. See above
> ...[noparse][[/noparse]something I did not suggest]
Well, you didn't suggest it, but it is part of the problem where a sizeof is the only help.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
> then also define a constant with the name sizeofVARNAME.
Yes, that does work, but only if I manually keep track of changes. That's exactly what I do *not* want to do.
This partly relates to "magic numbers"
I'm using (I'm not alone) constructs like:
So avoiding "magic numbers" and keeping the paradigm to make a change only in one place and not in three.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Sometimes it does not matter to not distinguish between the basic concept of contiguous cells of a linearly addressed memory and an "array"; sometimes - as with SPIN - it gives rise to the most phantastic ideas of what "should" work, or how it "should" work.
I shall not read this specific thread any longer, sorry
Post Edited (deSilva) : 12/27/2007 12:56:17 PM GMT
That's why there are two constants. I named the second one LongSize because the scenario you set up was an abstract one. But that constant is the size of the elements of the array. Whatever you call it, you change it from 4 to 2. As I said, one change.
However, if you changed the elements of the array from long to word, you'd have bigger considerations than that, given that LONG is a signed integer and WORD isn't.
It wouldn't do any harm for it to be there, but it's unlikely to be worth the changes to the compiler necessary to implement it. It's unlikely that the compiler retains the length of the array declaration part the point at which is compiles that statement. Implementing sizeof would require an extra column in the symbol table, and that's far from a trivial change, particularly is the compiler is really written in X86 assembler.
The fact is it's needed for C for three reasons:
None of these apply to Spin. Defining your data sizes with constants up front is all that is required to do any sizeof task. Sizeof is superfluous to Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Two constants, two places to make a change. First in the declaration, second in the constants.
<content deleted by moderator for violation of forum guidelines>
Nick
Post Edited By Moderator (Paul Baker (Parallax)) : 12/28/2007 6:12:47 PM GMT
It shouldn't be that hard to do, and I just added and tested a SizeOf function in one of my own compilers ( written in VB6 ) in just a few minutes to see how hard it was to do. Whether it's worth it should be measured by user necessity IMO not how difficult anyone made it for themselves through their choice of programming languages. I'd be a bit concerned if someone came up with a solution which was not easily extendible as that also implies to a degree not easy to fix or maintain. I expect Parallax wouldn't have a major problem implementing it if they chose to.
With huge quantities of cash ?
You can kludge together a runtime version which will return the base size of the variable or array but as there's no knowledge of an array's length at runtime that isn't as easy ...
CON _CLKMODE = XTAL1 + PLL16x _XINFREQ = 5_000_000 OBJ tv : "TV_Text" CON TV_PIN = 12 VAR ' The magic marker variables ( in any long, word or byte order ) long longMarker word wordMarker byte byteMarker VAR ' User declared variables ( in any long, word or byte order ) byte aByte word aWord long aLong long aLongArray[noparse][[/noparse] 10 ] word aWordArray[noparse][[/noparse] 10 ] byte aByteArray[noparse][[/noparse] 10 ] PUB Main tv.Start( TV_PIN ) ShowBaseSizeOf( String("aLong "), @aLong ) ShowBaseSizeOf( String("aWord "), @aWord ) ShowBaseSizeOf( String("aByte "), @aByte ) ShowBaseSizeOf( String("aLongArray "), @aLongArray ) ShowBaseSizeOf( String("aWordArray "), @aWordArray ) ShowBaseSizeOf( String("aByteArray "), @aByteArray ) ShowBaseSizeOf( String("aLongArray[noparse][[/noparse] 1 ] "), @aLongArray[noparse][[/noparse] 1 ] ) ShowBaseSizeOf( String("aWordArray[noparse][[/noparse] 2 ] "), @aWordArray[noparse][[/noparse] 2 ] ) ShowBaseSizeOf( String("aByteArray[noparse][[/noparse] 3 ] "), @aByteArray[noparse][[/noparse] 3 ] ) PRI ShowBaseSizeOf( strPtr, varPtr ) tv.str( strPtr ) tv.out( " " ) tv.dec( BaseSizeOf( varPtr ) ) case BaseSizeOf( varPtr ) 1 : tv.str( String(" Byte") ) 2 : tv.str( String(" Word") ) 4 : tv.str( String(" Long") ) tv.out( $0D ) PRI BaseSizeOf( varPtr ) if varPtr => @byteMarker result := 1 else if varPtr => @wordMarker result := 2 else result := 4(literally)
Seems to me, the time and energy spent grappling with getting SPIN to conform to other language constructs, is far better spent just simple understanding of how it works, then leveraging that.
It also seems to me, regularity and predictability, are two elements necessary for longer term sanity; therefore, kludging an operating environment, to behave in a fashion outside it's scope of intent, then differentiates ones efforts in a way that violates these two ideas, even though that may well be the intent! Having done this, one's body of code is then more difficult to merge and or leverage with other bodies of code, written with the language intent in mind. It's a net loss all around.
Understanding exactly how something works is half the problem. (IMHO, the more critical half) Realizing best case efforts, knowing that, is the other half.
For those, invested in specific means and methods, the effort of mapping one onto the other can often, at first glance, appear to be time well spent, as this leverages existing understanding and practice. However, doing this without full consideration for those things that differentiate a given platform (and I'm gonna label the Propeller as a platform --loosely for this expression), is highly likely to then marginalize the differentiators that made said platform worth realizing in the first place!
It's a Propeller! And it's significantly different from most other CPU's, and those differences have distinct advantages. (IMHO, that's exactly where the fun is!) There are some constraints in play, different from most other CPU's, that impact SPIN. Those same differences yield significant benefit at the same time. This mapping process is not as likely to pay off compared to other CPU's, largely because the Propeller just isn't like other CPU's, and that's the core of it right there.
Consider both, or consider none. Anything else is a complete waste of time and one will find it to be nothing more than an exercise in frustration at this time.
For what it's worth, this Propeller will see Large Memory Model C code very soon, which will somewhat marginalize it's overall utility (failure to realize full speed potential), but will at the same time, largely eliminate many of these discussions. Prop II, will reach a point in scale, where those differences, for a very large scope of applicable tasks, become adademic. (still some speed loss, but overall speed possible falls well within the scope required for many tasks)
Software driven design lies at the core of what the Propeller is supposed to be. That means everyone involved has the maximum amount of choice as to how to best apply the hardware. It also means some time to build the code elements necessary for greater numbers of people to get along. Finally, it means often being able to realize some specific functionality, with a minimum of additional hardware required, and that only promotes greater overall utility in general. The cost for that (and one just can't have everything) is some significant differentiation in how things are done at the silicon level. That has what should be obvious code implications.
The other elements of the Propeller are symmetry and determinism. Being able to re-purpose both hardware and software at the COG level, means some core changes in the chain of tools one uses to construct larger projects.
There is some learning that's gonna have to happen in order to take best advantage of these core things.
Bending SPIN into something other than what it is today, makes zero sense, given the above and some time passing.
Right now, at this point in time, SPIN is an entity as unique as the chip is! It is that way for a reason; namely, to make exploiting the advantages presented by the Propeller, more accessible to more people, easier than would otherwise be the case with assembly code alone. In this vein, SPIN hits the mark perfectly, and does it in a mere ~500 instruction words too boot! Combine it with assembly code, and the multi-processing elements of the chip, and you get something that has a very wide range of applicability. That was the target for the chip, it remains it's primary differentiator at this time, and through the next iteration of the core design.
Coming here, and (expletive)ing about, the cost of this applicability, in the form of non-compliance with other established means and methods, is just not productive for anyone involved.
Again, it's a Propeller. Go and look at the data sheet and consider what that means, then think about what SPIN does do, and leverage that accordingly, or wait for others to build middle ground tools. It won't be all that long.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 12/27/2007 6:49:40 PM GMT
<G> I fail!
> You can kludge together a runtime version which will return the base size of the variable or array ...
That's a clever trick!
> ... but as there's no knowledge of an array's length at runtime that isn't as easy ...
Well, at least you demonstrated how "complicated" it is to collect the data for a sizeof. I knew that before, but ... well ... there are better gurus than you and me.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
If Spin supported dynamic arrays or did automatic bounds checking, then a sizeof function would be mandatory. In its present state, however, "arrays" have no real bounds, so a sizeof function could be misleading to the casual programmer. But aside from that, the suggestion seems rather harmless and could even be useful in certain circumstances. Personally, though, I would continue to allocate space using a defined constant, a la CardboardGuru's example, and use that constant in lieu of sizeof.
-Phil
Ditto. I use named constants or simple constant expressions (x+1 or x-1) based on them for most array and loop bounds. Works great!
Well "should be" is neither here nor there. "Is" is what's being dealt with, and if it's true that the compiler is written in hand crafted X86 assembler, then it's true that changing the structure of a something as central as the symbol table is likely to be a major undertaking. This isn't a hobby compiler, but a released one that people rely on, so the extra functionality (minimal) needs weighing against the possibility of introducing new defects (significant). And that within the known situation that the compiler is a maintained by one person who usually has other priorities above adding new features. New features are going to be for things that are not possible already, not this.
Well, that part of the problem wouldn't be at all hard to add to the compiler anyway. The Symbol table must already notes the "base size" of a symbol to enable indexing etc. As you say, the "array size" is probably unknown beyond the moment is takes for the compiler to reserve the variable space for it.
Phil, Mike,
Indeed, it's hard to see how declaring a constant for the arraysize and then declaring the array from that variable is not perfectly adequate for the task. Good practive is to do that anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/29/2007 2:08:28 AM GMT
I could counter with "likely to be" is equally neither here nor there, that it would just be another field to add to the symbol table ( or the size can be derived by ascertaining the difference between its base address and the next allocated ) ... but there's enough (pointless) argument going on in this thread as there is.
Just because it's written in assembler doesn't mean it is a major undertaking to change things, but that does depend on how well written the code is and what consequences changing a core data structure has - ironically, a possible issue of SizeOf() itself
Mine's not a hobby compiler either and I don't see any significant risk of adding new defects unless the compiler is poorly designed. For mine it involved three changes; adding a field to the symbol table, setting that field when an array is defined ( zeroed if not an array ) and creating a factor function to handle SizeOf. No interactions there with any other existing code.
Thanks,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 12/28/2007 6:41:41 PM GMT
There's no arrays in C either ... an array is simply a pointer and the index is just added to that pointer. The only problem with this is that things like bounds checking and such are left to the programmer.
You for got to delete something, in your desperate attempt to keep the PC in this forum.
Search for "stupid"
Thanks,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I did complain about some of the Anglo Saxon Language you decided to use. It is a total shame when 10 year old kids read this type of stuff.
This happened to me. Life has rules, when I disagree with people I tend to just walk away. When I have nothing good to say then I tend to remain silent.
I know not helping now in this situation, what is the expression "Don't feed the trolls"
I believe that Paul took the correct action in this instance, he then also spent his time and created a new thread that laid things out in very simple terms.
With Regards
Mike.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 12/29/2007 3:01:57 AM GMT