Using both registry banks (the exx instruction) could speed things up a lot. I almost never use the IX and IY registers because they are very slow.

In contrast to what PingPong said, I prefer using hl as the address register. Then you can load the values into registers other than a. But I try to stay away from 16 bit arithmetic operations and when I need them I move the contents of hl into de using ex de,hl. Another benifit of having the address stored in hl is that you can do arithmetic operations directly with the value pointed to by hl, e.g. add (hl) which adds the value pointed to by hl with the value of the accumulator.

Another good idea is to set up your tables so you can do the equivalent of a = *ptr++ instead of indexed lookup. This often saves a lot. I used tables quite a lot in MSX Unleashed and other demos but they are structured quite different from what they would be in a C64 demo.

But the overall biggest saving you can do is to utilize all registers in both register banks and try to stay away from the IX and IY registers.

Quote:

Using both registry banks (the exx instruction) could speed things up a lot. I almost never use the IX and IY registers because they are very slow. In contrast to what PingPong said, I prefer using hl as the address register. But the overall biggest saving you can do is to utilize all registers in both register banks and try to stay away from the IX and IY registers.

most times having addresses stored in hl force us to do some math if hl serve as a base pointer. As in this example:

ld d,0
ld hl,xxxxxxx
push hl
ld e,someoffset
add hl,de
ld (hl),a ; store
pop hl
ld e,someoffset+2
add hl,de
ld (hl),a ; store


takes 88 cycles.

ld ix,xxxxxxxx
ld (ix+someoffet),a ; store
ld (ix+someoffset+2),a ; store

takes 52 cycles.

(I'm not assuming the m1 wait cycle)

As we can see IX / IY register are not so bad as we can think reading only timings in datasheets, surely depends on what should be done.
However, most times we need to to pseudo random access based on a value and because of this using hl and doing math on it has the following disavantages:

-Part of the fast access of HL is eat by the needing of loading some other register to do math and by the math operation itself.
-We destroy the previous value of HL, and we need some extra code to save it in the case we need back the original value.
-We do 16 bit math, slower than 8 bit math
-Because of 16 bit math we rapidly eat all available z80 register because the z80 use those register in pair (==> therefore had half the register available). Because of this we run more rapidly out of registers causing the need to save/restore registers in memory, and falling in poorer performance results than if we simply use all register including IX,IY

@tokumaru:
Far by me the idea to compare the cpu performances, (Make sense, comparing two snails to see what is less snail!?, both are snails!). I would only point that most of the times things are not as easy appear at first approach. We rarely can say:

I hate this way, the second is ALWAYS FAR BETTER. Not at all, depends.

Regarding speed: you will find the z80 a bit slower if you had coding on 6502 running at half of z80 clock. To be honest, because of architectural of z80, a 6502 running at 1Mhz perform like a z80 @2.5Mhz (also here depends, but is a roungly exact value ).

What i liked on 6502 was mainly:
-ortogonal asm
-sofisticated addressing modes (post & pre), that are very cool. (if they made 16 bit wide they would be perfect!)

Quote:

(if they made 16 bit wide they would be perfect!)

The 65816 (CPU used in the SNES) has them, and it's backwards compatible with the 6502, AFAIK.

I think all these old processors (used in 8 and 16-bit gaming systems) are fascinating.

Quote:

I think all these old processors (used in 8 and 16-bit gaming systems) are fascinating.

Indeed!, I love the Z80; but the 6809 beats it in every aspect. Its a shame that it never breaks with success the 2Mhz barrier, very few variants were produced above this speed

I use ix and iy a lot. All extra regs are welcome. They are still faster than ld a,(hhll). Also very
usefull is the jp (iy) instruction, wich is faster aswell. Un-aligned criss cross table acces, again
a verry usefull feature. Not to mention you can now use hl for math. Even load data directly
into a reg, like ld l,(ix+0) ld h,(ix+1) even frees de for other stuff.
You can add or substract data and it takes the same amount of cylces to load (only 19 ).
All and all they are very useful.

Indeed, the deal with IX/IY is knowing when to use them. We all fear the 20+ t-state monster, thus avoiding it, but at times it can actually be faster than trying to find some workaround. The biggest gain is ofcourse in setting up your tables. For pure speed, nothing beats a bunch of $0100 aligned 'HL tables'. Try to see if perhaps you can split your tables in a few smaller ones, and if you manage to align them neatly you can save yourself the 16bit addition. Working with these old beasts is really more a matter of tricking them into thinking they're real CPUs, and at times it works!

Quote:

Quote: (if they made 16 bit wide they would be perfect!) The 65816 (CPU used in the SNES) has them, and it's backwards compatible with the 6502, AFAIK. I think all these old processors (used in 8 and 16-bit gaming systems) are fascinating.

I know, one 16 bit variant of z80 is z380, that add relative sp addressing, mulitplication, higher addressable ram size etc.

The 6809 was also a great cpu (especially in speed), but if you want really the best (IMHO), take a look at 68000

- Lot of registers
- Can do both memory or register operations (easily)
- Fast
- 16/32 bits architecure
- Ortogonal and very clear istruction set.


I only complain to not have this on early PCs instead of the horrible 8086/286!

Quote:

The 6809 was also a great cpu (especially in speed), but if you want really the best (IMHO), take a look at 68000

I know, I know, it's my favourite assembler! , I used to love it when programming the Amiga!. I just don't mention it because it plays another league, I can hardly compare this great CPU with other like Z80, 6502 and 6809...
The only drawback I found when I moved from Z80 and 8086 assemblers was the lack of memory block moving instructions; but soon I realized that it was nothing to worry about...

Quote:

Actually many C compilers use IX or IY to manage the heap during function calls. the heap is used both for local variables and for parameter exchange, so the code of the function accesses to the local variables by many LD A,(IX+offest) Also automatic variables are stored on the heap and accessed by LD A,(IX+offest)

Ehm, sorry to disappoint you, but that's not the heap, that's the stack.
The heap is used for malloc() & friends.

Quote:

Quote: Actually many C compilers use IX or IY to manage the heap during function calls. the heap is used both for local variables and for parameter exchange, so the code of the function accesses to the local variables by many LD A,(IX+offest) Also automatic variables are stored on the heap and accessed by LD A,(IX+offest) Ehm, sorry to disappoint you, but that's not the heap, that's the stack. The heap is used for malloc() & friends.

Was a lapsus obviusly...

AuroraMSX -- isn't malloc() used to obtain memory for structs? So then, variables (run-time variables, that is) would be accessed using the heap, or am I wrong? Bah -- had the compiler construction course a long time ago, so I don't remember very well

- stack is for local automatic variables
- heap for local static variables & global variables
- dinamically allocated memory blocks are in the heap also, and a pointer to memory block is stored in the heap/stack.

Quote:

- stack is for local automatic variables - heap for local static variables & global variables - dinamically allocated memory blocks are in the heap also, and a pointer to memory block is stored in the heap/stack.

Static variables and global variables are typically located in other memory segments (although it is compiler dependent). Initialized variables are usually located in the .data section and non initialized in .bss (they are usually initialized to zero). So they are not allocated from either the heap nor the stack.

I have a quick access method (self modifying code again) that I haven't seen in the posts, please correct me if I overlooked it.
It works for fixed tables, 0100h aligned, but uses no HL or anything else except A but obviously the code has to be in ram:

ld (next+1),a
next:
ld a,(tablestart)

It simply modifies the second ld a, (nn) command. If the table low byte is 0, this is the fastest you can get, methinks. Akin and especially Core Dump are full of these