Author Topic: Opcodes that should have been incorporated into the Z80 processor (Read 16992 times)

chickendude · « **Reply #15 on:** February 04, 2013, 02:53:32 pm »

Bump. Today i was thinking once again how i wish there were an easy way to transfer registers to their shadow counterparts, like a version of exx that instead of swapping registers copied them. So you could do something like this:
exx' ;copy hl, bc, and de to hl', bc', and de'
;mess up hl, bc, and de
exx ;restore original register values (shadows contain the "messed up" values)

tr1p1ea · « **Reply #16 on:** February 04, 2013, 06:17:43 pm »

has anyone mentioned div or sqrt?

Xeda112358 · « **Reply #17 on:** February 05, 2013, 06:39:47 am »

@chickendude: I have thought about that, too o.o What if there was a way to refer to a specific shadow register, even if it were an extended instruction. This way you could do something like ex hl',hl or copy hl,hl'.

@tr1p1ea: If there was such a command, it would detract from the fun of creating a multiplication or division routine

willrandship · « **Reply #18 on:** February 05, 2013, 11:10:07 am »

Not to mention fastinvsqrt!

A project I've been thinking about actually addresses this kind of issue: Imagine a processor where all the undocumented instructions are just small FPGA logic grids. You can make them do pretty much anything, as long as it's not too long or insane. (Ie put reg A in reg B while writing reg A to a memory location)

TIfanx1999 · « **Reply #19 on:** February 06, 2013, 05:38:42 pm »

Quote from: Xeda112358 on February 05, 2013, 06:39:47 am

@chickendude: I have thought about that, too o.o What if there was a way to refer to a specific shadow register, even if it were an extended instruction. This way you could do something like ex hl',hl or copy hl,hl'.

@tr1p1ea: If there was such a command, it would detract from the fun of creating a multiplication or division routine

Fun she says...

Multiplication and division would have been nice tbh.

fb39ca4 · « **Reply #20 on:** February 06, 2013, 08:16:08 pm »

TBH, we should just move on to another, more modern architecture that has all of these features. Once you know how to structure a program in ASM for one architecture, writing it for a different architecture isn't that hard.

calc84maniac · « **Reply #21 on:** February 06, 2013, 08:59:00 pm »

Quote from: t0xic_kitt3n on February 06, 2013, 08:16:08 pm

TBH, we should just move on to another, more modern architecture that has all of these features. Once you know how to structure a program in ASM for one architecture, writing it for a different architecture isn't that hard.

What's the fun in that?

tr1p1ea · « **Reply #22 on:** February 06, 2013, 09:12:49 pm »

Haha i do agree with Xeda and calc84 in that it wouldnt be as fun as figuring out how to beat limitations if these features were there

.

Spyro543 · « **Reply #23 on:** February 06, 2013, 09:16:45 pm »

Quote from: t0xic_kitt3n on February 06, 2013, 08:16:08 pm

TBH, we should just move on to another, more modern architecture that has all of these features. Once you know how to structure a program in ASM for one architecture, writing it for a different architecture isn't that hard.

PIC, anyone?

willrandship · « **Reply #24 on:** February 06, 2013, 09:46:02 pm »

How about an FPGA based environment? Get a high-quality chip, something with a few million logic cells (preferably with an open source development environment) and it's easy to make a soft processor plus all sorts of extra hardware that can be reconfigured in real time.

Imagine being able to build a logic structure that calculates your graph in parallel, or a 3D graphics accelerator that handles your rendering. FPGAs are cool.

ruler501 · « **Reply #25 on:** February 06, 2013, 11:25:24 pm »

FPGA's are awesome. In a robotics competition I'm competing in there is an FPGA onboard which I am learning to program

harold · « **Reply #26 on:** February 08, 2013, 07:39:29 am »

ldmsr reg16 11101101 11[reg16]0000 put reg16 into the model specific register at the index specified by register A.
stmsr reg16 11101101 11[reg16]1000 stores the contents of the msr indexed by A in reg16.
cpuid 11101101 01110111 puts cpuid data indexed by register A in A, and sets the carry if A <= max cpuid index (otherwise leave the carry and A unchanged)

These encodings made sense to me, but maybe there are better ones.

As for the MSRs,

0 settings bits 1 - 15 are reserved and must be zero. bit 0 indicated whether the interrupt stack MSR is used.
1 interrupt stack if settings[0] is 1: when an interrupt occurs, SP is stored in user stack and SP is then loaded with interrupt stack before pushing PC.
2 user stack receives the value of SP when an interrupt occurs and settings[0] is 1.

If interrupt stack is used, RETI and RETN are changed to do their thing with the interrupt flip flops, pop the return address off the stack, then load userstack into SP, then jump to the return address.
This thing is meant for making interrupts not screw with the stack the running program was using, enabling some optimizations that previously required interrupts to be disabled to leave them running.

I'm pretty sure MSRs could be used to create a place for MMU settings to be, so an MMU can be included in the z80 proper (not having to go through ports), but I'm too lazy to think of a nice way to do it.

As for cpuid, it conditionally sets the carry so you can check whether it's supported like this:

Code: [Select]

xor a
cpuid
jnc _not_supported

And to make things easy, the cpuid data indexed by zero is max cpuid index, indicating the maximum value you can ask cpuid for.

If cpuid is not supported, it corresponds to an undocumented NOP, which won't set the carry.

There should probably be a bit in the cpuid data indicating support for MSRs. Say, bit 0 of cpuid[A = 1].

thepenguin77 · « **Reply #27 on:** February 08, 2013, 07:39:51 pm »

How could I have forgotten some of the obvious ones:

   ex   de, ix
   ex   de, iy

   sbc   ix, bc
   sbc   ix, de
   sbc   ix, ix
   sbc   ix, sp

   adc   ix, bc
   adc   ix, de
   adc   ix, ix
   adc   ix, sp

These are all the instructions that you've always assumed existed until you tried to use them. With both the EX's and the SBC's, I was so angry when I used them in my code only to find out that they don't exist.

And, if we want to be hopeful

   ldix
   ldiy
   lddx
   lddy

   ldirx
   ldiry
   lddrx
   lddry

These would be really cool, even if they did take 4 more t-states per iteration.

DrDnar · « **Reply #28 on:** February 08, 2013, 07:46:45 pm »

ld hl, sp
ld ix, sp
ld iy, sp

And an indexRegister+reg8 addressing mode.

But, you know, pipe-lining like the eZ80 has would be just as nice.

SpiroH · « **Reply #29 on:** February 09, 2013, 09:27:12 am »

Quote from: Hot_Dog on March 13, 2012, 07:21:30 pm

If too many opcodes are put into a processor, it becomes expensive. But sometimes there are commands that we Z80 programmers use so often, we wonder why they don't exist in the Z80 hardware by default...we wonder why we have to code the routines ourselves.
....

Well, it all depends on what time frame you're talking about.

Z80 was born around 1976 (just about 37 years old!). So, its no wonder that the price of the silicon chip area has changed a LOT since then. Actually, today it would be easily possible to produce a Z80 pin-compatible device with a much improved instruction set and probably much cheaper also. You would need to unsolder (unplug) the original grandpa and replace it with a much brighter grandchild. It can be a hobby or a hard/software student thesis for some of you. Just firing up into the stars...

Author Topic: Opcodes that should have been incorporated into the Z80 processor (Read 16992 times)

chickendude

Re: Opcodes that should have been incorporated into the Z80 processor

tr1p1ea

Re: Opcodes that should have been incorporated into the Z80 processor

Xeda112358

Re: Opcodes that should have been incorporated into the Z80 processor

willrandship

Re: Opcodes that should have been incorporated into the Z80 processor

TIfanx1999

Re: Opcodes that should have been incorporated into the Z80 processor

fb39ca4

Re: Opcodes that should have been incorporated into the Z80 processor

calc84maniac

Re: Opcodes that should have been incorporated into the Z80 processor

tr1p1ea

Re: Opcodes that should have been incorporated into the Z80 processor

Spyro543

Re: Opcodes that should have been incorporated into the Z80 processor

willrandship

Re: Opcodes that should have been incorporated into the Z80 processor

ruler501

Re: Opcodes that should have been incorporated into the Z80 processor

harold

Re: Opcodes that should have been incorporated into the Z80 processor

thepenguin77

Re: Opcodes that should have been incorporated into the Z80 processor

DrDnar

Re: Opcodes that should have been incorporated into the Z80 processor

SpiroH

Re: Opcodes that should have been incorporated into the Z80 processor