Perhaps PRI drawLines(pLine: sLine, count) | i, i.e. var: type? This is what Python and Rust do. But would this interact badly with specifying types on return variables?
We went over this in the live forum meeting today and decided to just keep the ^.
I am going to add passing and returning of whole structures that can fit in the method parameters and return values. Tonight I added passing structures whole, and I think returning whole structures only requires some compiler changes. Lots to think about and it overflows my mental stack a bit.
@Rayman said:
Is the order of elements within the structure kept as written or reordered in some way?
Also is everything stored in longs even if bytes? Or, compacted?
Everything is kept in the order. It was declared and it is all packed without regard to alignments.
When structures get passed on the stack as parameters and return values, they will need to be rounded up to the next long, in size, so they amount to a number of whole longs.
Hi Chip, i have a Problem with PNUT v44.
My P2 Projekt ist very big and I want to rewrite it with the new structures in V44.
With PNUT v35u it compiles without Errors.
With PNUT v44 it compiles with Error: "OBJ data exceeds 1024k limit."
Can you expand the OBJ data space in v44?
I think the structures in V44 are very very useful, but I need a built-In Method sizeof(struct) witch return the structure length in bytes.
Hi Chip, I try the other PNUT versions.
The Error: "OBJ data exceeds 1024k limit." comes with v37 - v44.
In v37 "Parameterization to child-object instantiations" is added and I think this will take much more OBJ data space.
@macca said:
Please update the Spin interpreter source (and any other updated sources) in both the package and git repository.
Thanks.
Will do, but there is a problem:
I have been changing the way data structures work, so that in the next version, there may be differences in how you use them. I hope to have this done soon, but it will need another week of time to get ironed out.
@wummi said:
Hi Chip, I try the other PNUT versions.
The Error: "OBJ data exceeds 1024k limit." comes with v37 - v44.
In v37 "Parameterization to child-object instantiations" is added and I think this will take much more OBJ data space.
I need to discover why this is happening. I think it may have to do with CON data being treated as part of the binary image space, initially, but I am not sure yet.
@macca said:
Please update the Spin interpreter source (and any other updated sources) in both the package and git repository.
Thanks.
Will do, but there is a problem:
I have been changing the way data structures work, so that in the next version, there may be differences in how you use them. I hope to have this done soon, but it will need another week of time to get ironed out.
No problem, it was a "general remainder" to update the sources, I noticed that even in v43 the source was still a bit older.
I'm a bit behind with the structure implementation and for now I'm more interested in implementing the new methods since they have renumbered the existing bytecodes.
Haven't been keeping up with this but in this table, shouldn't the syntax have had the first and last lines of this list reversed, so the [] indicates a pointer dereference operation is in play. Won't it be confusing to have ptrval directly access the pointed to variable without something indicating that is what you want to do? For all other cases with the brackets present you would know it some sort of special pointer dereference except for the first one.
I share Roger's concern. For parameters the current specification works well and may be what we want. But how do pointers declared in the VAR section, or as local variables, work? They don't naturally have anything to point to, so they somehow have to be initialized. Also, do the post/pre increment operations on pointers use the size of the pointed to object, like C, or do they increment by 1 (like Spin2 normally does)
@ersmith said:
I share Roger's concern. For parameters the current specification works well and may be what we want. But how do pointers declared in the VAR section, or as local variables, work? They don't naturally have anything to point to, so they somehow have to be initialized. Also, do the post/pre increment operations on pointers use the size of the pointed to object, like C, or do they increment by 1 (like Spin2 normally does)
It works a bit like a C++ reference, the pointer is syntactically equivalent to the pointee. So you'd need to use [name] := @something to initialize it. Note that pointer increment is name[++] (so name++ increments the pointee) and per the last line of that changelog, increments by item size.
Syntax like [ptrvar++] and [--ptrvar] would seem a lot more natural to me than ptrvar[++] and [--]ptrvar. I imagine this syntax is already valid just based on how compilers tend to work, even if it currently compiles to worse bytecode.
This is a very radical change to Spin2, essentially adding types to variables. As long as we're doing that, why don't we make floating point variables?
...to access the pointee is that we are then not far away from just doing...
BYTE[var]
My attempt at pointers was to minimize the typical cruft.
Yeah I'd sort of guessed that was the reason for this, but it does seem to complicate the syntax and make it look reversed from what you'd expect and perhaps a little clumsy (talking from a C point of view with actual pointers, not references).
...to access the pointee is that we are then not far away from just doing...
BYTE[var]
My attempt at pointers was to minimize the typical cruft.
I absolutely understand @rogloh's and @ersmith's thoughts, but I really like the minimization; simply referencing the pointer name returns the value it's pointing at.
I also like C, but I've always felt that C pointers were defined backwards and it's caused many programmers to screw up many times; not just me.
My thoughts are...
Variables in C have types. One of those possible types is pointer (... to some type).
In C, an INT variable's purpose is to hold, and be used as a reference to, an integer-type value.
You don't have to constantly "dereference" an INT variable to access ("reference") its value as an INT... so why should you have to constantly dereference a pointer variable to access the value it is meant to reference? By definition, pointing (to an INT, for example) is its very purpose in life... it's the point of its existence, yet C always makes us expend extra effort to use it for its intended purpose.
@cgracey, how do you access individual bytes of a LONG value pointed to by ^LONG ptr?
ptr.BYTE[0]?
ptr.BYTE[1]?
or
BYTE[[ptr]][0]?
BYTE[[ptr]][1]?
Also...
@cgracey said:
ptrvar[--]--
That would post-decrement the pointed-to variable and post-decrement the pointer by whatever the size is (1/2/4).
Does that decrement the pointed-to variable first, then decrement the pointer by its size?
...to access the pointee is that we are then not far away from just doing...
BYTE[var]
My attempt at pointers was to minimize the typical cruft.
I absolutely understand @rogloh's and @ersmith's thoughts, but I really like the minimization; simply referencing the pointer name returns the value it's pointing at.
I also like C, but I've always felt that C pointers were defined backwards and it's caused many programmers to screw up many times; not just me.
My thoughts are...
Variables in C have types. One of those possible types is pointer (... to some type).
In C, an INT variable's purpose is to hold, and be used as a reference to, an integer-type value.
You don't have to constantly "dereference" an INT variable to access ("reference") its value as an INT... so why should you have to constantly dereference a pointer variable to access the value it is meant to reference? By definition, pointing (to an INT, for example) is its very purpose in life... it's the point of its existence, yet C always makes us expend extra effort to use it for its intended purpose.
@cgracey, how do you access individual bytes of a LONG value pointed to by ^LONG ptr?
ptr.BYTE[0]?
ptr.BYTE[1]?
or
BYTE[[ptr]][0]?
BYTE[[ptr]][1]?
Also...
@cgracey said:
ptrvar[--]--
That would post-decrement the pointed-to variable and post-decrement the pointer by whatever the size is (1/2/4).
Does that decrement the pointed-to variable first, then decrement the pointer by its size?
You would use...
ptr.BYTE[0]
ptr.BYTE[1]
...just like you would a regular variable.
That would effectively change ptr into a byte pointer, even causing...
[--]ptr.BYTE[1]
...to pre-dec ptr by 1 (not 4). That would have the net effect of reading the byte initially pointed to by ptr, with ptr dec'd by 1.
ptr[--].BYTE[1]
...would post-dec ptr by 1, reading the byte at ptr[1] with ptr dec'd by 1.
I think it is true that C established in people's minds what was not optimal, a long time ago. The angst over non-convention is undue. It's just upsetting to what became traditional thinking.
Comments
It's something like 16 longs I think.
I believe it's 16 as that's the number of parameters you can pass to a method.
In the P2 meeting Chip just said that its 128 longs.
That's a quarter of total cogRAM! If you use all that then I bet you'll be taking an axe to usable space for things like regload().
Parameters can be from 0 to 127 longs .
Return values can be from 0 to 15 longs.
Ok, seems like enough to pass some sensibly sized structures by value then
We went over this in the live forum meeting today and decided to just keep the ^.
I am going to add passing and returning of whole structures that can fit in the method parameters and return values. Tonight I added passing structures whole, and I think returning whole structures only requires some compiler changes. Lots to think about and it overflows my mental stack a bit.
Is the order of elements within the structure kept as written or reordered in some way?
Also is everything stored in longs even if bytes? Or, compacted?
Everything is kept in the order. It was declared and it is all packed without regard to alignments.
When structures get passed on the stack as parameters and return values, they will need to be rounded up to the next long, in size, so they amount to a number of whole longs.
Hi Chip, i have a Problem with PNUT v44.
My P2 Projekt ist very big and I want to rewrite it with the new structures in V44.
With PNUT v35u it compiles without Errors.
With PNUT v44 it compiles with Error: "OBJ data exceeds 1024k limit."
Can you expand the OBJ data space in v44?
I think the structures in V44 are very very useful, but I need a built-In Method sizeof(struct) witch return the structure length in bytes.
Please update the Spin interpreter source (and any other updated sources) in both the package and git repository.
Thanks.
Hi Chip, I try the other PNUT versions.
The Error: "OBJ data exceeds 1024k limit." comes with v37 - v44.
In v37 "Parameterization to child-object instantiations" is added and I think this will take much more OBJ data space.
Will do, but there is a problem:
I have been changing the way data structures work, so that in the next version, there may be differences in how you use them. I hope to have this done soon, but it will need another week of time to get ironed out.
I need to discover why this is happening. I think it may have to do with CON data being treated as part of the binary image space, initially, but I am not sure yet.
No problem, it was a "general remainder" to update the sources, I noticed that even in v43 the source was still a bit older.
I'm a bit behind with the structure implementation and for now I'm more interested in implementing the new methods since they have renumbered the existing bytecodes.
Thanks Chip,
I removed the parallel arrays from my LED Matrix driver and replaced them with data structures.
HydraHacker
@cgracey
Any further thoughts or progress on enabling command line specification of the comm port for download?
Thanks,
The new PNut_v45 is done and posted at the top of this thread.
Looking good. Please don't worry, I don't have time for LF today. (Might poke my head in later)
Haven't been keeping up with this but in this table, shouldn't the syntax have had the first and last lines of this list reversed, so the [] indicates a pointer dereference operation is in play. Won't it be confusing to have ptrval directly access the pointed to variable without something indicating that is what you want to do? For all other cases with the brackets present you would know it some sort of special pointer dereference except for the first one.
I share Roger's concern. For parameters the current specification works well and may be what we want. But how do pointers declared in the VAR section, or as local variables, work? They don't naturally have anything to point to, so they somehow have to be initialized. Also, do the post/pre increment operations on pointers use the size of the pointed to object, like C, or do they increment by 1 (like Spin2 normally does)
It works a bit like a C++ reference, the pointer is syntactically equivalent to the pointee. So you'd need to use
[name] := @somethingto initialize it. Note that pointer increment isname[++](soname++increments the pointee) and per the last line of that changelog, increments by item size.Also, it could allow extensions down the track for other things such as these, which seem more readable to me.
Syntax like
[ptrvar++]and[--ptrvar]would seem a lot more natural to me thanptrvar[++]and[--]ptrvar. I imagine this syntax is already valid just based on how compilers tend to work, even if it currently compiles to worse bytecode.You have it the wrong way around -
ptrval++increments the pointee,[ptrval]++increments the pointer.This is a very radical change to Spin2, essentially adding types to variables. As long as we're doing that, why don't we make floating point variables?
--ptrvar[++]
That would pre-decrement the pointed-to variable and post-increment the pointer by whatever the size is (1/2/4).
ptrvar[--]--
That would post-decrement the pointed-to variable and post-decrement the pointer by whatever the size is (1/2/4).
[ptrvar]++
Like Ada said, that would just increment the pointer.
Lots of possibilities. And triggers, I understand.
The thing about using...
[ptrvar]
...to access the pointee is that we are then not far away from just doing...
BYTE[var]
My attempt at pointers was to minimize the typical cruft.
Yeah I'd sort of guessed that was the reason for this, but it does seem to complicate the syntax and make it look reversed from what you'd expect and perhaps a little clumsy (talking from a C point of view with actual pointers, not references).
I absolutely understand @rogloh's and @ersmith's thoughts, but I really like the minimization; simply referencing the pointer name returns the value it's pointing at.
I also like C, but I've always felt that C pointers were defined backwards and it's caused many programmers to screw up many times; not just me.
My thoughts are...
@cgracey, how do you access individual bytes of a LONG value pointed to by ^LONG ptr?
ptr.BYTE[0]?
ptr.BYTE[1]?
or
BYTE[[ptr]][0]?
BYTE[[ptr]][1]?
Also...
Does that decrement the pointed-to variable first, then decrement the pointer by its size?
You would use...
ptr.BYTE[0]
ptr.BYTE[1]
...just like you would a regular variable.
That would effectively change ptr into a byte pointer, even causing...
[--]ptr.BYTE[1]
...to pre-dec ptr by 1 (not 4). That would have the net effect of reading the byte initially pointed to by ptr, with ptr dec'd by 1.
ptr[--].BYTE[1]
...would post-dec ptr by 1, reading the byte at ptr[1] with ptr dec'd by 1.
I think it is true that C established in people's minds what was not optimal, a long time ago. The angst over non-convention is undue. It's just upsetting to what became traditional thinking.