Accessing tables with Z80 ASM

Page 3/3
1 | 2 |

By Sonic_aka_T

Enlighted (4130)

Sonic_aka_T's picture

11-07-2006, 13:51

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! Tongue

By PingPong

Prophet (3907)

PingPong's picture

11-07-2006, 18:54

(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!

By jltursan

Prophet (2619)

jltursan's picture

11-07-2006, 19:35

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! Smile , 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... Tongue
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... Smile

By AuroraMSX

Paragon (1902)

AuroraMSX's picture

12-07-2006, 14:17

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.

By PingPong

Prophet (3907)

PingPong's picture

12-07-2006, 17:55

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

By [D-Tail]

Ascended (8259)

[D-Tail]'s picture

12-07-2006, 23:39

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 Tongue

By PingPong

Prophet (3907)

PingPong's picture

12-07-2006, 23:47

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

By dvik

Prophet (2200)

dvik's picture

13-07-2006, 05:24


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

By parallax

Expert (85)

parallax's picture

27-07-2006, 16:39

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 Smile

Page 3/3
1 | 2 |