Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: amos on February 04, 2020, 11:33:38 PM

Title: H2 DM memory issue
Post by: amos on February 04, 2020, 11:33:38 PM
I recently did an upgrade to a process with a domore and ran into the 256 limit on Memory Blocks. Is there any plan on increasing the limit? I guess if the Memory Blocks could be 2 dimensional I could get away with less than 50.
Title: Re: H2 DM memory issue
Post by: franji1 on February 05, 2020, 09:05:24 AM
If you need 2D arrays, emulate it with a 1D array.  This is how simple multi-dimensional arrays work in C, so this is common practice in the Computer Science world.

Say you want a 2D array of REALs called AR, 5 rows by 7 columns.  You would normally index it as AR[row#][col#].  AR is really just a block of memory containing 35 REALs (5 x 7).  The index lookup is where the power of multi-dimensional arrays works.

But it's easy to calculate a 1D index via a 2D row, column index.

I like to use symbolic constants in Do-more.  So create a symbolic constant for the number of COLUMNs in AR, e.g. AR_NUM_COL equal to 7.

Here's the simple formula for a 1D index (V99) from a Row value (say V0) and Column value (say V1).

Code: [Select]
V99 = (V0 * AR_NUM_COL) + V1

[R][C]
[0][0] is 0
[0][1] is 1
. . .
[0][6] is 6
[1][0] is 7
[1][1] is 8
. . .
[4][0] is 28
[4][1] is 29
. . .
[4][6] is 34

I'm sure you are using some kind of "lookup" with REFREAD/REFWRITE to generate a block # index (it may must be a simple MATH box, or a bunch of relational comparison/assignments, regardless)

This new array index calculation can be a simple index (not a block #):

MATH V42 "(V100 * AR_NUM_COL) + V101"  (replace V42/V100/V101 with your actual V array index values)

Then, simply index AR with V42 in any relational contact or instruction or wherever as AR[V42]

Here's a 2D FOR/NEXT loop to initialize all the values to a random number using RANDREAL() MATH function:

Code: [Select]
FOR V100 0 4  // row # 0..4, inclusive
  FOR V101 0 6  // col #  0..6, inclusive
    MATH V42 "(V100 * AR_NUM_COL) + V101"
    MATH AR[V42] "RANDREAL()"
  NEXT
NEXT

What's also good, is that the 2D array indexes can be anything - constants, D memory, a struct member, but the result 1D array index must be a V to be utilized in any instruction.  So, you could easily initialize the 2nd column (0-based column index 1) across all 5 rows to a Random number as follows:

Code: [Select]
FOR V100 0 4  // row # 0..4, inclusive
  MATH V42 "(V100 * AR_NUM_COL) + 1"  // the "+1" is the column index for the 2nd column
  MATH AR[V42] "RANDREAL()"
NEXT

or initialize the 3rd row to a random number (0-based row index 2):

Code: [Select]
FOR V101 0 6  // col #  0..6, inclusive
  MATH V42 "(2 * AR_NUM_COL) + V101"  // the "2 * " is the row index for the 3rd row
  MATH AR[V42] "RANDREAL()"
NEXT
Title: Re: H2 DM memory issue
Post by: BobO on February 05, 2020, 12:41:20 PM
And depending on how the second dimension is to be used, you might also be able to use a UDT.
Title: Re: H2 DM memory issue
Post by: amos on February 05, 2020, 08:44:45 PM
Thank you franji1. Yes that could have easily worked. I'll have to think of that in the future. After all, all the memory blocks are less than 100 words long. I did look at UDT's too. It would have been a lot of work to change the design of the memory structure.
  Thank you for the replies.