[Slackers] Slangdef, part 2

[Magnus Lind]

Steve Judd wrote:
> int ^b(100)
> 
> will allocate table lookup data (100 elements worth).  All of this is to
> say that
> 
> byte ^c(0)
> 
> only works for bytes.

Ok, this breaks a few assumptions I had about slang arrays and pointers 
to arrays. I wasn't aware that using arrays and pointers to arrays can 
result in lookup tables. I didn't expect this 'extra' memory usage.
This means that I'll have to really think about when to use arrays and 
array pointers and of what size I should declare the pointers.

The comments and questions that follows are about arrays and array 
pointers that use lookup tables. In other words, arrays and array 
pointers that have an element size != 1.

I can see the point of lookup tables when using multi dimensional arrays 
and with element sizes that are not a power of two, like floats. But for 
arrays of integers wouldn't it be possible to shift the index and be 
able to do without a lookup table for nearly the same speed?

> My suggestion is to put the number of elements you expect to use in the
> array definition.  They won't be allocated, but I think it provides
> clarity and, yeah, possibly array boundary checking may be added sometime
> (maybe as a debug mode).

But each declaration would allocate a lookup table, right?
And if the size is too small then I would be unable to index the array 
pointer beyond that point?

By disassembling test programs I have deduced that arrays use absolute 
lookup tables and pointers to arrays use relative lookup tables.

Would it be possible for array pointers of the same type to share their 
relative lookup tables? This would really save space for multiple array 
pointers of the same type. Further, would it be possible for plain 
arrays to use the shared relative lookup tables too in order to save 
even more space (That is, at the expense of one additional 16 bit add 
operation)?

/Regards

Magnus Lind