sprites like MJ's Trabajo Basura (not unregr. Fourspriter)

[AlcoholicsAnonymous]

Using IY would be nice. I'm thinking in relocating TIMER routine into RAM and free IY regs. (or just use something like PUSH IY, di, call routine, POP IY, EI, RET).

Yeah I wouldn't want to mess with that either -- it is something basic programmers expect. There's a point where the basic system just gets in the way and you are probably there now.

I also think structs should be a plus, but I haven't yet figured out how to implement them efficiently in a so limited machine: na_th_an suggested using IY+n scheme to reference struct fields, but IY is used by the TIMER interrupt routine.
How did you implement structs?

As you say the addressing modes are limited so there is no clear preferred solution. I always look to what machine code programmers do and I think compilers should try to emulate that if possible.

m/c programmers organize the data in their structs so they can be walked, reading and writing data as it is needed. Random access in the struct is avoided if possible. So in my own asm code I use HL to point at a member in the struct and I am doing a lot of 'LD r,(hl); inc hl' in there as needed. That makes it 13 cycles (and two bytes) per sequential access vs 19 cycles (and four bytes) per random access using an index register. z88dk is using this method and retains the current struct ptr in hopes future accesses are near past accesses. In ideal situations this should lead to smaller code if not faster code but it depends on the programmer organizing the struct in a good order as the compiler will not reorder struct members.

There are a lot of ifs and maybes in that so it may be more efficient (not to mention easier) to do indexed register access for the general case. z88dk has chosen not to intrude on asm extensions (user code or library) so it has avoided using index registers or reserve registers for exclusive use for that reason. The thought has been (I guess since I was not there from the beginning but I do go along with it) that strong optimization would be introduced to resolve a lot of issues and maximum performance would come out of asm library code where most execution time would be spent. We don't have that uber optimization yet and there is still a long way to go.

In other words, I don't have the right answer

[britlion]

Like so many things, AA - it's often a question of asking which is the lesser of the evils, and in the end you have to make a choice.

It's not always the way everyone would like, mind. It's like the speed vs size question - sometimes one way is the right answer, and sometimes the other. Because I want more games programmers to find ZX Basic accessable, I've been leaning towards speed over size fot the library routines I'm writing. On the principle that the size version often fits into more standard zx basic routines anyway - perhaps with rom calls, anyway...

[slenkar]

maybe module writers could specify if the module is written for speed or size,and make 2 versions
ah dunno

[boriel]

maybe module writers could specify if the module is written for speed or size,and make 2 versions
ah dunno

+1 :!:

In fact, these can be done already using #IFDEF
e.g. We could create an ID like OPT_MEM or OPT_SIZE, and do something like:

Code:

...
#ifdef OPT_MEM
...
// Code for memory optimization goes here
...
#else
...
// Code for speed optimization goes here
...
#endif

The compiler could then insert a
#define OPT_MEM at the beginning, using a flag like --opt=mem or --opt=size,
or much simpler: the programmer can insert a #define OPT_MEM at the beginning of the code.

This could be very handy for things like:

• FP routines (using routines provided by Britlion, for example, instead of ROM ones).
  
• Using ROM drawing & printing primitives (CLS, PRINT, DRAW, PLOT, CIRCLE)

The program will be slower, but definitely shorter (e.g. for text adventures, or games having many rooms, etc).

[slenkar]

yep thats a good idea, so the module writer writes both versions of his function in the IFDEF statements
then the user copy-pastes the whole function into the IDE and sets the DEF to size or speed, nice