[Slackers] Slangdef, part 2

[Steve Judd]

Hey Magnus,

> 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.

Well, it's really not much memory.  The code generation is the bigger
eater of memory.

> 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?

In general, array access is of course

addr = base + offset1*val1 + offset2*val2 + ...

The calculation may either be done manually, or using a table.  Since the
"C64 way" is to use a table, that's what Slang does.

In general, there is one table for each dimension, with the base address
included in the first table.  Each table will have Nx rows, where Nx is
the number of elements in dimension x; tables may be 8-bit, 16-bit, or
24-bit values as needed.  The maximum table size is 256 entries.

The exceptions are byte arrays.  With byte arrays, the last dimension may
be added in directly, without any need for a table lookup.  As an example,

ubyte scr(25,40)@$0400

generates one table with 25 16-bit entires for the 1st dimension, for 50
bytes total.  (The 2nd dimension is added in directly, and needs no
table.)  As another example,

ubyte blah(200)@$c000

doesn't allocate any table at all.

So now, why not use ASL with ints?  There are several reasons.  For
starters, the offset still has to be added to the base address.  And you
can't just do

	lda arg1
	asl
	adc #base	;oops -- carry set wrong
	sta zp
	...

but instead have to do

	lda arg1
	asl
	sta temp
	lda arg1+1	;or lda #00
	rol
 	sta temp+1
	lda temp
	clc
	adc #<base
	sta zp
	lda temp+1
	adc #>base
	sta zp+1

So the code is already getting clunky.  Moreover, the code becomes
inefficient (due to adding in the base address), and is actually larger.
Now access that array many times -- say, 5-10 times? -- and the extra code
can become larger than the table.  With Slang I usually chose speed over
compactness, but in this case I believe the Slang method is actually more
compact overall for most programs.

Another reason is that 3- and 4-byte ints are possible in Slang, by
changing/updating slangdef.  I just used 2-bytes for convenience.

In general, with Slang, my goal was to do things like assembly.  For small
byte-arrays in asm, I normally use X or Y directly.  For larger arrays, I
normally use lookup tables.  Slang does likewise.

> 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?

With byte arrays you can cheat, since the last dimension does not allocate
any table.

Otherwise, with normal arrays, the table size is the declared number of
bytes.  If you exceed that size, the table lookup code will produce
garbage.

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

For the most part, yeah.  The base address is added in to the 1st
dimension table, unless the 1st dimension has >256 elements.

>
> 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)?

Well, I will think about it.  Slang produces fairly large code, and my
sense is that lookup tables are a really tiny fraction of total code size.
Moreover, I rarely see C64 programs that actually use up all memory.  When
memory is that tight, Slang probably isn't the best choice.

But I will think about it...

-S