EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 155 of 197

There is no algorithmic reason why the maximum dimension has to be 10. MAX_DIM is used internally for storing information about the dimensional start and extent. cases the (double ****) cast. This is required to match the assigned to pointer f.-om the void pointe r returned by daaO and daavO. The valid subscript values for each array dime nsion are determined by ta king the sta rting subscript, as defin ed by the st[] array, and adding the con-esponding dimension extent, as defin ed by the de] array, and sub- tracting 1. Thus, for th e previous arrays, the valid subscript ra nges are -1 to +1, -5 to -1 , 10 to 13, and 0 to 1. If you address elemen ts of the array with any subscr ipts outside these lim- its, the result is just as wro ng as a sim- ilar addressing mistake in conve n- tional arrays. if the subscr ipting mistake is only off by a few elements, the e rro r may silen tly slide by; howev- er, more serious mistakes often result in segmentatio n fa ults, at least on workstatio ns. if tile application is a fixed-size array, the call to dasO before daaO would then be removed and a #define ·ubstituted with the known size. Put anotller way, it is clearly unnecessary to caJi das() repeatedly only to re turn the same size. In a dynamic environ- me nt th e dasO/ maLLocO/ daaO sequence will be needed. I often use daaO or daavO, even witll fixed-size arrays, to be able to modi fy tile an-ay in a subroutine and sti ll be seen in the caller. The extreme case of] O-dimension- al allocatio n will result in an unusual cast. For example, let's assume an array of doubles. The fo llowing code would result: doubLe **********array; array = (doubLe **********) daa(); array[i][j][k][L][m][n][o][p][q] [r] = 1.0; Test 4 of tile test suite does exactly this with varying dimen ional extents and starting subscripts. The locality of reference and the non-zero subscripting are certain ly use- fed. However, the most usefu l feature by far is tile abi li ty to pass such arrays to subroutines and get visibili ty of sub- routine modifications to the array with- o ut having to do any tiling special such as taking addresses or using global data. In fact, I have used these routines in applications where I allocated a multid imensional array and passed o nly a slice of the allocated array to subroutines for modification. This is incredibly convenient. Assuming the allocation of a four-dimensional array, tll is is demonstrated by: upkg(bpd, array[i][j], &err_ code); Here the bpd SU-ucture contains bit- packed data th at is unpacked in upkgO into the right-most two sub- scripts of array[][][][] and passed back as the two-d imensional sub-array of array[i ][jl New and improved Ten years ago, I wrote an article on an earlier versio n of tll is code. I The basic allocation scheme and the fun ctional intent is the same. However, I have made several enhanceme nts: • The old daaO, now called daavO, was o riginally not designed fo r embedded use. A new embedded version, the new daa(), has been added • The test suite has been expanded . All tests are now independent and both daaO and daavO are tested • The code has been made compli- ant wi til tile ANSI C standard • The data and pointer areas have been reversed to allow the heap space library rou tine to allocate space at tile most stringent bo und- ary for data storage • The code to align tile pointer space on a pointer alignment boundary 154 DECEMBER 2000 Embedded Systems Programming has been added-Sun 's cc will fix any misalignment, but gcc will not • The code is now re-enlrant Internals Only four error returns are possible, all resulting in a ULL return value. These are: • A check that the number of dimen- sions is greater than zero and less than or equal to MAX_ DIM • A check tllat the data size of Lhe first argument is greater than zero • A check that each dimensio nal extent is greate r than zero • A check of the va L LocO return value The first three checks are applicable to dasO and daaO whi le all fo ur apply to daavO. Error-free operation return a non-NULL pointe r to voi d that should be cast to the lype of the intended array and does not sel *err_code. There is no algorithm ic reason why the maximum d imension has to be 10. MAX_DIM is used internally fo r storing information about the d imensional start and extent. If, for some reason, you want mo re dimensions, jusl increase MAX_DIM and recompile. Ten seemed li ke a good round number that most applications wo uld be unlikely to exceed. Decreasing or increasing the limit calTies no perfor- mance benefi t or penalty. The total memory ize of the allo- cation is th e sum of two parts. The first part is the actua l data, which is immediately followed by the pace of pointers to pointers to ... that poin t, eventually, to th e last layer of point- ers, and then to the data. The size of these two parts is calculated by: num- be r of data eleme nts * size of data ele- men t + number of poin te rs'" size of poin te r (plus a few bytes up to si ze- oH char *) to align tile pointer area). On Unix system , do a pagesi ze com- mand to see how much space you have before the allocation runs into a sec- ond page or how many total pages

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13