Compiler Speed Trials

[boriel]

This does raise a question, Boriel:

Could the compiler recognize a case of dealing with, say, a one dimensional array, and handle that completely differently - say by hanging onto the index in a register (or register pair)? The overwhelming majority of arrays are one dimensional - and it's of course possible in a cross-compiler to build in optimized options for different cases. (we don't have the memory limit for this sort of thing we have for an on-spectrum compiler!)

Sure, if someone wants an 8 dimensional array, good luck to them - the compiler handles that. (Which is utterly staggering, by the way. This is the most flexible compiler for the spectrum by far!). But, having said that, since probably 90% of arrays are single dimension, I'd say the possibility of making that a special case the compiler creates the tightest code for, might be worthwhile.

Most arrays are 1 or 2d, that's right. But keep in mind we're being compatible with Sinclair BASIC and FreeBASIC. It's just Z80 is not very powerful. There's an alternative (faster) way to calculate the offset, but requires much more memory: A table of pointers to pointers to pointers... (a table of pointers per each dimension), so it just requires Sums + pops (no multiplications). I could try some kind of #pragma fastarray to enable them.
Anyway, you (and I mean all of you) might be making the same mistake I explain here. You don't want BASIC. You want C with "BASIC keywords", to suit your needs (e.g. writing games). This will eventually degrade the language to a low-level C-like one (and people will prefer C instead). :|

The main idea of ZX BASIC is to compile Sinclair BASIC programs into machine code (which has been almost achieved, perhaps READ, DATA and RESTORE could be added in the future).

Then think of having a high level language. There are some problems here with that:

• High level languages require less code, but are difficult to compile or must be completely interpreted (like BASIC VAL "2 * x + sin(y + 1)").
  
• They also add some overhead to the execution trying to guess what we, the humans, wanted to do. So some high level things must not be used in critical parts. e.g. in the critical cycle of a game painting.
  
• They also add some memory overhead (so 48k might be not enough...)

Okay, but they also bring more interesting things: They make your program shorter, easier to maintain and to port; you will probably come back to your program after a long time and remember what your program is trying to do without much commenting; it's more productive and even portable.

So for what you're trying to do, instead of breaking array support, you should try a different approach: e.g. implement a vector object yourself in ASM. It can be done. There are functions called allocate and deallocate already implemented in <alloc.bas>. Use them to create a dynamic memory block.
Then access your block with an addr integer variable, and read it with PEEK(<typesize>, addr). This is a pointer (ZX BASIC currently does not implement them, so you have to work this way).