Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: plcnut on August 25, 2016, 05:13:03 PM
-
I need the equivalent of a REFWRITE, but I need to use it for strings.
Can this functionality be added? Or am I missing an instruction that will do it for me?
-
Currently, no. One possible work around would be to set up a bunch of BYTE data blocks, then use STRGET/STRPUT whenever you needed the data in string form.
Are all your string block strings the same Max Length?
-
Are all your string block strings the same Max Length?
Yes, they are all the same.
I ended up just making one large string block and then using STRPRINT with my index. Now I use index 0-99 for 1, 100-199 for 2, 200-299 for 3, etc.
The REFPRINT instruction would be great though!!! ;D
-
Or just n-D arrays. Most REFWRITE cases would be addressed if we had multiple dimension arrays, I believe.
-
Multidimensional arrays would be great! I cannot remember where the thread was where we talked about it... Are there going to be multidimensional arrays in DMD 2.0?
-
I think the current word is not initially, but hopefully eventually.
-
Multidimensional arrays would be great! I cannot remember where the thread was where we talked about it... Are there going to be multidimensional arrays in DMD 2.0?
No. Not too hard to manage though, now that MATH boxes support expressions in the output parameter. If you had a two dimensional array that was ROWS x COLUMNS, with V0 being the first dimension index and V1 being the second, the read and write syntax is simply aMyArray[V0*ROWS + V1]. Yes, it's limited to a MATH box, but it's only marginally harder to code than aMyArray[V0][V1].
-
That's a decent solution, but not completely, exactly analogous because it's wangling a one-dimensional array into behaving [somewhat] like a 2D. Accessing one cell at a time, there are a lot of viable solutions
But...the primary reason I want N-D arrays has to do with accessing multiple elements in one shot, where solutions like this one fall down. For example, I might use a bit array MyBitArray[0..256][0..5000], because I want there to be a syntax that lets me WRITE all the bits in MyBitArray[52][243...789], but I'm READING the array orthogonal to the way I'm writing: MyBitArray[][2157] should return some structure containing 256 bits.
-
That's a decent solution, but not completely, exactly analogous because it's wangling a one-dimensional array into behaving [somewhat] like a 2D. Accessing one cell at a time, there are a lot of viable solutions
But...the primary reason I want N-D arrays has to do with accessing multiple elements in one shot, where solutions like this one fall down. For example, I might use a bit array MyBitArray[0..256][0..5000], because I want there to be a syntax that lets me WRITE all the bits in MyBitArray[52][243...789], but I'm READING the array orthogonal to the way I'm writing: MyBitArray[][2157] should return some structure containing 256 bits.
That is pretty much exactly the way C implements arrays under the covers, because all memory is a one dimensional array. There is exactly a 0% chance of multi-dimensional arrays being implemented in Do-more until we do a major overhaul of some critical internal constructs, which very likely happens when we do a future class of processor in which we want to greatly expand memory capacities, but not until then. In the meantime, if your goal is to index memory using two or more indices, the solution I offered is not bad.
-
That is pretty much exactly the way C implements arrays under the covers, because all memory is a one dimensional array.
Granted -- so I guess the distinction I'm making would be syntax that treats all the dimensions interchangeably. IOW, "under the covers" is good! Normally, like you guys, I favor the Better Toolbox over the Finished Coffee Table paradigm, but in this case I'd value a good layer of abstraction.
There is exactly a 0% chance of multi-dimensional arrays being implemented in Do-more until we do a major overhaul of some critical internal constructs, which very likely happens when we do a future class of processor in which we want to greatly expand memory capacities, but not until then.
Looking forward to it! :)
-
Kicking this can again to keep it alive. To recap -- the reason I want a formal N-d syntax is to stripe across the array along an arbitrary selection of axis or axes.
You're quite right that reading or writing one cell at a time using that workaround is quite viable, as are others, but if that's all you do, why would you need an N-d array in the first place?