Data Typing.
gmkuka
Posts: 16
My current project requires 3 serial ports (Cogs) monitored by an additional Cog, which·provides the interface to a 'Standard' world. All of these are character based.· I struggled to get this to fly because of one simple problem. Determining where a 'Long Value' comes from when assembling a string of bytes in a buffer. I input a string of 0...254 characters, it's no matter, the string is always 4 bytes long and consists of 4 $FF bytes... After a while it hit me that this is actually a 'Long' with a -1 value. I was unable to determine where this came from... And, in the rabid events to follow in an effort to figure this out, for a reason I still do not know... It works... And very well... The problem was not programmatic, the solution was in something I typed regarding 'Data'.
I have the first port functioning very well and have begun bringing up the second port... I'll be switched, it works too... Sort of... This puppy has an extra character plunked in at the very beginning of the buffer. Of course this is a multiple call kind of thing... So... The second pass and beyond, does·NOT add any additional·characters... AND... The code is identical to the first cog, only with a set of it's own variables pecular to itself... I mean Copied and 'Search & Replace' the symbol names... As·was the 'Var' definitions, a unique set with the necessary different name.
All·access code for each section is identical and makes moves on it's own set of variables...
The only rational idea·I can come up with is... There's a secret about this 'Data System' that I don't know... Something like 'Every Good Boy Does Fine' in music... Twenty-Five years plus back, I paid my 'C' data type dues... Geez, this can't be that difficult... Yet, simplicity has it's dangers...
Any ideas or suggestions... My concepts of what it should look like and what it actually does are quite shakey at this point in time.
gmkuka
·
I have the first port functioning very well and have begun bringing up the second port... I'll be switched, it works too... Sort of... This puppy has an extra character plunked in at the very beginning of the buffer. Of course this is a multiple call kind of thing... So... The second pass and beyond, does·NOT add any additional·characters... AND... The code is identical to the first cog, only with a set of it's own variables pecular to itself... I mean Copied and 'Search & Replace' the symbol names... As·was the 'Var' definitions, a unique set with the necessary different name.
All·access code for each section is identical and makes moves on it's own set of variables...
The only rational idea·I can come up with is... There's a secret about this 'Data System' that I don't know... Something like 'Every Good Boy Does Fine' in music... Twenty-Five years plus back, I paid my 'C' data type dues... Geez, this can't be that difficult... Yet, simplicity has it's dangers...
Any ideas or suggestions... My concepts of what it should look like and what it actually does are quite shakey at this point in time.
gmkuka
·
Comments
It very much depends on what drivers you use, if any, of how your COGNEWs look like, and maybe, maybe can even a variable in one of the three pieces of code that has not been renamed correctly...
And...
Is there any other explanation / demonstration of it's/their use? Other than the simple pdf supplied examples...
Thanks for your help...
gmkuka
- to replicate the allocation of byte, word or long values in the DAT section
- to reserve a string of long cells on the stack in the local variable definition part
- to reserve a string of bytes, words or longs in the VAR section
- to access the n-th element after a certain variable, whether this be a byte, word, or long depends on the "type" of the variable
- to access the n-th byte, word, or long wrt a "pointer"
This is very assembly language like, quite flexible, not good looking in many cirumstances, and open to many misunderstandings.
I agree it "looks" like arrays in other languages when you constrain the application to trivial cases.
Post Edited (deSilva) : 10/17/2007 1:54:01 PM GMT
I've listened to all those responding and I appreciate greatly your interest in helping me solve my problem... And after hearing what everyone was saying, I felt compelled to test this whole thing... So the last day or so I've been running some tests... in an attempt to replicate the problem without the complexities of 'Code' and stuff... In that pursuit, I found the following...
After scanning through anything that has/had data declarations, looking for size constraints on the elements of declared data... And... other than the proverbial, you can't fit 1.0MB into a 32KB space without compression... Nothing significant was stated...
The attached 'spin' demonstrates the kind of thing I was seeing when I started out on this adventure... It uses the Manual's VAR example data declaration for the three given 'Sizes'... Followed by something I would use for my project... Long, Word and Byte symbols and arrays...
Run the program as it stands... It·shows various ways to assign a 'Long' to a 'ByteArray' that has been 'Cast' to be the correct·size. It shows that the 5th entry, the 'Long' assignment is 'Offset' by -2 Bytes.
Change the 'str[noparse][[/noparse]10]' to 'str[noparse][[/noparse]11]' and the 'Long' offset grows to -3 Bytes. AND... Now the previous line shows the 4th entry, the 'Word' assignment to have a -1 Byte offset error.
If the declaration is 'Odd', both 'Long' and 'Word' assignments are offset from their true location. If the declaration is 'Even', then only the 'Long' goes offset...
If the declartion is an integral of 4, a 'Long', all is well... Could not locate this fact. I was standing in the forest and could not see the trees...
This all makes sense...My program kb command buffer is 32 bytes long... Plus 1 for termination... 33! Kb worked fine... It was the 'ByteArrays' that followed the KbBuf that had the access problem I described...
Tell me what you think.
Thank you, gmkuka
I am happy to hear that you read what we write - in fact that is necessary, because many things are MOST DIFFICULT TO FIND ANYWHERE ELSE
In fact you have no real chance - and there is no need that you do! - to find out many peculiarities of SPIN data allocation of your own.
(a) VARs re re-sorted according to the rule: LONGs first, then WORDs, BYTEs last.
(b) DATs however are padded
(c) The Prop is a little-endian machine
(d) You need sometimes 64 byte allignement that is not available the easy way...
I shall not carry on to assembly code ...
Sorting alone does not solve this problem... If a odd number of bytes of 'Byte' stuff preceeds more 'Byte' stuff that is Long/Word accessable, failure is eminent. The 'str[noparse][[/noparse]11]' could easily be on the line directly preceeding 'Barray' and 'After' all the other stuff, size sorted.
It's safe to use one of the following.
Declare all byte elements last, as you said and then 'Size Sorted' amongst themselves, largest array first, decending in size to the smallest.
Any byte VAR greater than 1 byte should be padded to 4. <OR> Make Dang sure you won't access any of the following bytes on an 'Odd'/'NonLongIntegral' index as Longs/Words.
Declare single byte elements last.
Thanks again,
gmkuka
ps: is gmkuku my nickname or is deSilva a poor typist?
Your "rules" for safety really don't address the underlying behavior of the compiler. If you understand that, your "rules" are not necessary. deSilva's four points are correct. In addition:
It really doesn't matter what order you declare items in unless you want to represent structures or unless your program makes an error and accesses something beyond the space allocated for the variable (like trying to access the 12th byte of an 11 byte array.
If you want to represent structures and all the elements are the same storage type (byte, word, or long), the compiler will maintain the order of declaration without padding.
You cannot (CANNOT!) mix storage types in declarations if you expect the storage allocated to be contiguous. The compiler will reorder the declarations (in a VAR section) to put longs first, then words, then bytes or pad things to the proper boundary (in a DAT section). If you want to store values smaller than the storage type, declare a structure of the proper alignment type, then access the elements you want using a byte or word suffix (like array.byte[noparse][[/noparse]xx] where array is a long array and you want to use a byte subscript to access individual bytes).
Spin doesn't have structures in the sense of Pascal or C. If that doesn't fit how you would like to construct programs, wait for the C compiler from ImageCraft in the next couple of months. That should make this sort of thing easier and more natural for you. It will come with its own set of limitations as well as advantages, but that's how these things go.