New assembler for Z80

Hallo All!

Since such a binge has begun...

Maybe it’s true, who will write a new assembler for the Z80. So I have one strange proposal. No, it will not concern perversions, such as turning ASMA into Fortran or Si... We will talk about one "little thing" in the standard Z80 mnemonics, which has been annoying me for a long time... As everyone should know, the Z80 processor was designed as an improved version of the 8080, it executes all its commands, but the syntax of its assembler was significantly different redone. Let me give as an example the equivalent commands of 8080 and Z80:

MOV M,D LD (HL),D
INR M INC (HL)
ADI 5 ADD A,5
DAD B ADD HL,BC
PCHL JP (HL)
SPHL LD SP,HL
XCHG EX DE,HL
XTHL EX (SP),HL
CPE 100h CALL PE,100h
RNZ RET NZ
POP D POP DE
IN FDh IN A,(FDh)
CMC CCF

Is it necessary to prove which syntax is clearer? True, the text in Assembly Language
8080 is a little more compact, but are brains really cheaper?

Now I’ll get down to business. Still, the developers of the Z80 mnemonics got a little greedy and left several “shortened” commands. :( Is there any logic to specify
a single register in “double” operations? For example:
ADD A, B
SBC A, B
but
AND B
SUB B

The habit of “shortened” records later plays a cruel joke. A couple of times I tried
to force TASM to compile the XOR AX command ;)
Let's make it more uniform if we are to make a “new assembler”?
So that the correct form of commands is:
AND A,B
SUB A,B
XOR A,A
And the compiler will be simpler, and programmers will not develop bad
habits...

For the same reasons, wouldn't it be more logical instead of commands
IN r, (C)
OUT (C),r
to write
IN r,(BC)
OUT (BC),r

Further, especially for sclerotics like me ;) why not introduce
"non-existent" mnemonics, which differ from the correct ones only in the order of arguments:
EX DE,HL EX HL,DE
EX AF,AF' EX AF',AF
EX (SP),HL EX HL,(SP)
EX (SP),IX EX IX,(SP)
This is not an attack on “principles,” is it? And I’m much more accustomed to putting
“accumulator registers” AF and HL before the comma...

Maybe it’s worth introducing “full” forms for “single-place” operations with an accumulator, and instead of
CPL
NEG
write
CPL A
NEG A
by the way, maybe at the same time we can rename CPL to NOT , much more familiar? Although
anyone can do this using a macro...

And instead of
RLD
RRD
write
RLD A,(HL)
RRD A,(HL)
(I don’t insist...)

And finally, the last question. What form of recording should be considered "standard" for undocumented triple operations? Like SET 7,(IX),A

These are my proposals, formed over several
years of programming in Assemblers of different processors. At first glance, they may seem like an encroachment on the “sacred cow,” but besides all
other things, this form of recording will allow the compiler to more strictly control the algorithm formulations that the programmer wrote down. For example, it will be possible to catch an error like NEG HL or SUB B,B ;)
It is also important that with such skills it will be easier to take up programming in 80x86 Assembly Language. Offtopic is offtopic, but life is life
and many more Spectrumists will most likely have to study it...
Naturally, in addition to the “new” Assembler, it is advisable to immediately create a
“new” disassembler, but this task is much simpler...

George

Hello, George!

Sunday April 20, 1997 18:05, George Shepelev wrote to All the following words:

GS> Hallo All!

GS> Since such a booze has begun...

GS> Maybe it’s true, who will write a new assembler for the Z80.
But you can also screw up the old one...
GS> So I have one strange thing proposal.
But this is good. I wish there were more letters like this. At least they are
interesting to me.

[introduction skipped]

GS> Now I’ll get down to business. Still, the developers of the Z80 mnemonics were a little greedy and left a few “shortened” commands. :( Is there
GS> logic to specify a single register in “double” operations?
GS> For example:
GS> ADD A,B SBC A,B
GS> but AND B SUB B
Or maybe it’s better = ADD B and SBC B ?

[skip]

GS> For the same reasons, isn’t it more logical instead of commands
GS> IN r,(C)
GS> OUT (C),r
GS> write
GS> IN r,(BC)
GS> OUT (BC),r
and you try to write this in ZASM 2.xx - 3.xx. It will compile for you.

GS> Next, especially for sclerotics like me ;) why not enter
GS> "non-existent" mnemonics that differ from the correct ones only in the order of arguments:
GS> EX DE,HL EX HL,DE
GS> EX AF,AF' EX AF',AF
^^^^^^^^^ we have already shortened to EXA
GS> EX (SP),HL EX HL,(SP)
GS> EX (SP),IX EX IX,(SP)
GS> This is not an attack on “principles”? But I’m much more accustomed to putting
GS> “accumulator registers” AF and HL before the comma...

GS> Maybe it’s worth introducing “full” forms for “single” operations with an accumulator
GS>, and instead of
GS> CPL
GS> NEG
GS> write
GS> CPL A
GS> NEG A
IMHO, typing more is worse.
GS> By the way, maybe at the same time we can rename CPL to NOT , much more familiar? Although
GS> anyone can do this using a macro...
it’s really better to do it with a macro.

[skip]
GS> And finally, the last question. What form of recording should be considered “standard
GS> for undocumented triple operations? Like SET 7,(IX),A
but this is interesting. This will not compile in ZASM. Is it necessary?

GS> George

zy: At the end of April there will be a demo of ZASM v3.10!

Best wishes, Konstantin.

[Team ZX ASM] [Team Dos Navigator] [Team DOOM]

KA> But you can also screw up the old one...

It’s still interesting that you, as the only author of the “living” Speck assembler in the echo, think about the possibility (and necessity) of changing
(adding) the command syntax?

That is. It’s clear that this crazy idea can be implemented on a PC. And on Spec?

If it comes down to tokenizability, then, IMHO, even the
assignment operator should fit well into tokens (hence, relatively
quickly assemble)

TVP P TK P TK P TK P ..., where:
TVP-token of the assignment expression (for, for example, LET)
P-variable/constant/register
TK-token of a command in an expression (assignment, math/log operation, etc.)

TKs can overlap in values the codes of tokens of ordinary commands, since
they are found only in an expression.

Still, for example, the LD command ... is also quite ambiguous, but you somehow cope with
it :)

...And then look, ZASM 4.0 will be released :))

Warm greetings, Slava.

GS> Maybe it’s true, who will write a new assembler for the Z80. So I
GS> have one strange proposal. No, it will not concern perversions,
GS> such as turning ASMA into Fortran or C... We will talk about one “little thing”
GS> in the standard Z80 mnemonics, which has been annoying me for a long time...

[missing...]

Isn’t it easier to provide in the compiler the ability to allow some
“liberties” in the syntax of standard commands? What has already been implemented a long time ago in many ASMAs? For example, in MASM they will correctly understand both EX AF,AF' and EXA
And ZASM - OUT (C),A and OUT (BC),A

GS> These are my proposals, formed over several
GS> years of programming in Assemblers of different processors.

Under _one_ Z80 processor there are many _different_ assemblers - for them
too It was worth spending some time...

GS> At first glance, they may seem like an encroachment on the “sacred
GS> cow.”

Changing mnemonics “in one direction” is really stupid. There are too many
programmers who are already accustomed to the Sinclair standards and do not get confused by them.
It's all a matter of practice...

GS> but, among other things, this form of notation will allow the
GS> compiler to more strictly control the formulations of the algorithm that the
GS> programmer wrote down. For exampleIt will be possible
GS> to catch an error like NEG HL or SUB B,B ;)

What kind of compiler misses this?

GS> It is also important that with such skills it will be easier to take up
GS> programming in 80x86 Assembly Language. Offtopic is offtopic, but life
GS> is life and many more
GS> spektrumists will most likely have to study it...

Or maybe we’ll start right away with Fort? Since it is so cool.

GS> Naturally, in addition to the “new” Assembler, it is advisable to immediately create
GS> a “new” disassembler, but this task is much simpler...

New disassembler, new literature on programming... And all because you
get confused in some mnemonics...

GS> George

Regards, Dmitry (OLDMAN).

Hello Vyacheslav !

Monday April 21 1997 01:42, Vyacheslav Mednonogov ─── Evgeny Milun:

VM> Wow, the conversation has started :)
Businesslike and constructive. ;)

VM> L=A>> 3
F ;is it possible to represent the shift like this (?)
EM>> ^^ a-g-a, but he said “problems”.

VM> Well, here the question arises - who: RRC X or RR X.
It all depends on how compact it should be. If it is not particularly compact, but readable, then you can: ">C>" - RRC X, ">>" - RR X. If it is compact, but not particularly readable, then ">]" - RRC, ">>" - RR. Or something like that.

VM> And for SRL X you can
VM> enter the following notation - /2,/4,/8,.../128. Accordingly, *2,*4,...,
VM> for SLA X
IMHO, in principle this is superfluous, although it is clear.
VM> Unary inversion remains uncovered (probably it is CPL? or
VM> NEG?) - turn it into binary - ~1 (1-from the bullshit), i.e. С=B~1:

VM> ld a,b
VM> cpl
VM> ld c,a
IMHO, “~1” is more likely for NEG, but for CPL it’s better to just “~”.

VM> /skip/
EM>> And where is the “don’t care” here? IMHO, everything is fine. You're being modest,
EM>> my friend.

VM> I meant that you can force the assembler to turn an expression-chain of constants
VM> into oneconstant. But it’s better, IMHO, to actually put it in brackets []
VM> - everything will be completely unambiguous and inside it will be possible to use
VM> operations unusual for ASMA (division, remainder, multiplication, etc., etc.)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a-ah-ah, that’s what you’re talking about. Yes, you will have to insert a calculation block into the compiler. But, on the other hand, why are there divisions, remainder, etc. at all? ?

[.....]
VM> /skip/

VM>>> c) subtraction - apparently, you will have to forcefully precede
VM>>> with the command OR A
EM>> What if you need to subtract taking into account Carry ? Although, to do this, you can enter
EM>> one more action - subtraction taking into account carry, for example, "--".
VM> IMHO, word-by-word subtraction taking into account carry is more typical for 32-bit
VM> operations, which are mainly manipulated by M. Kondratiev ;)
Well, never say. Sometimes this (carry accounting) is also necessary with 16 bits.

VM> Like:
VM> sub hl,de
VM> exx
VM> sbc hl,de
VM> We just haven’t gotten to this topic yet (and we’re unlikely to get there :))
Yes, I haven’t gotten to “that” yet either. ;))
VM> Still, maybe you can suggest a general form of operations with words (you can
VM> count on constructive criticism :))
Well, I’ll suggest it. ;))) Just not now - I need to think about it.

VM> By the way, I see another difficulty: how to immediatelydetermine whether the
VM> operation will be one/two-byte if the first operand is (memory)? Those. (mem1)=hl and
VM> (mem1)=a. I can suggest modifying the expression operator. If
VM> used LET, then, for example, enter LETW. If you used <.>, then
VM> enter <..> or <:> or <,>. A little bad, of course. I like dot-dot
VM> better :))
Have you tried putting a dash? ;))

VM> -------------------------------------------------------------
VM> -

VM> Description of subroutines. Slightly simplify the original version (do not
VM> use the word var):

VM> PROC name (in_reg1, ... ,in_regN)
VM> USES preg1,reg2,...
VM> ...
VM> RETURN

VM> where:
VM> - in_reg1,...in_regN - registers or register pairs (excluding of course
VM> SP) - reg1,...regN - register pairs that will be saved
VM> (probably, you should take into account the mechanism for saving alternative registers,
VM> separating them, for example, with a semicolon) As was said, RETURN
VM> differs from just RET in that it first restores from the stack
VM> registers saved by USES.
You knew, you knew. ;)))

VM> [It is possible to enter ENDPROC (if you use
VM> separate compilation of codes and data), as well as SEGMENT name and ENDSEG -if
VM> compilation into different segments is provided, for example for overlays - but this
VM> we have gone too far :))) ]
^^^^^^^^^^^^^^^^^^^^^ Nothing like that. I have already “lived up to” overlays, and
I won’t say that writing them now is a pleasure. In general, you provide a mechanism for
normal writing of overlays!

VM> It is better to call the usual CALL, but with parameters:
VM> CALL name(in_ext1,in_ext2,...in_extN)
VM> this will literally turn into the following:

VM> LD in_reg1,in_ext1
VM> ...
VM> LD in_regN,in_outN
VM> CALL name

VM> If parameter M is omitted, the current value for input_regM will be taken.

VM> The main thing is that the original is again reduced and readable better. text. And also
VM> automatically checks for the presence of parameters and type compatibility.

VM> There is an unpleasant subtlety :( The procedure must be described before its
VM> first call.
Well, people write in Pascal, but it’s the same there.
VM> If this does not suit you, you will have to introduce a mechanism
VM> of pre-descriptions (replace the word PROC in the description with, for example, FORWARD)

Good luck !

EM> It all depends on how compact it should be. If
EM> is not particularly compact, but is readable, then you can: ">C>" - RRC X, ">>" - RR X. If
EM> is compact, but not particularly readable, then ">]" - RRC, ">>" - RR. Or something like this.

... or "->", or "}}", etc. It's fine.

EM> IMHO, "~1" is more likely for NEG, but for CPL it's better to just "~".

I just wanted one size fits all. And the separate "~" - where does it go? Like
C=B+~D ?

/skip about calculations during assembly/

EM> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ah-ah, that's what you're talking about. Well, you'll have
EM> to insert a calculation block into the compiler. But, on the other hand, why
EM> there are divisions, remainder, etc. at all. ?

I don’t know :) I’ve always been there (even in gens). Somehow familiar...

Hello George!

Sun Apr 20 1997, George Shepelev concocted a letter to All:

GS> IN FDh IN A,(FDh)

;)

GS> make a “new assembler”, let’s make it more uniform? So that
GS> the correct form of commands is: AND A,B SUB A,B XOR A,A AND
GS> the compiler will be simpler, and programmers will not develop bad
GS> habits...

There is only the first freshness and the “correct” forms already exist and cannot be given
others. Another question is the “personal biased forms” of one particular programmer. Having a good macroassembler, you can do everything
mentioned for yourself, without causing hemorrhoids to your neighbors.

EM>> It all depends on how compact it should be. If it is not particularly compact, but is readable, then you can: ">C>" - RRC X, ">>" - RR X. If it is compact, but not particularly readable, then ">]" - RRC, ">>" - RR. Or something like this.

Hello, Dmitry!

Saturday April 26, 1997 14:23, Dmitry Grigoryev wrote to Konstantin Afendikov these
words:

DG> Thursday April 24, 1997 07:10, Ilya Aniskovets wrote to Konstantin
DG> Afendikov:

DG> [missed...]

GS>>>> HL,DE EX AF,AF' EX AF',AF
KA>>> ^^^^^^^^^ we have already shortened to EXA

IA>> By you?! MASM 1.0... Or would you say that there was something soviet before us, except
IA>> TASM?
.... and he singled it out! Well, I apologized for 'us'... Ж8)

DG> [missed...]

GS>>>> considered “standard” for undocumented triple
GS>>>> operations? Like SET 7,(IX),A

IA>> Look at MASM 1.0 there is all the recording form, like in STS.

KA>>> but this is interesting. This will not compile in ZASM. Is it necessary?

DG> I’m wondering... Does the new ZASM converter know about all this?
If he doesn’t know, we’ll teach him! Ж8)
DG> The old one didn’t even know MASM’s pseudo-macros
he already understands 2x2... as well as _normal_ (almost) macros of himself
Ж8)

IA>> With Best Regards,
IA>> Ilya .

DG> Sincerely, Dmitry (OLDMAN).

DG> -+- GoldED 3.00.Alpha2+
DG> + Origin: * ON-LINE newspaper * (2:5020/689.31)

KA>> But you can also screw up the old one...

VM> It’s still interesting that you, as the only author of the “live”
VM> Speck assembler in the echo, think about the possibility (and necessity) of changing
VM> (additions) of the command syntax?
about everything that you all wrote about under the topic %subject% I can say one thing - IMHO, _for now_ this does not threaten the Spectrum. Readability of expressions is, of course, good, but optimizing the code during compilation will be a _BIG_ problem. Ж8(
By the way, one of the main advantages of the _assembler_ ZX ASM v2.xx, which I then switched to after TASM2, and then continued writing together with
Vova Rubtsov, was (and is) writing commands _through_colon_. On
one page everything is before your eyes, everything It looks great, and there are about 3-4 dozen Tasmov and other pages.

As for changing the syntax of commands... Don't change it, but add it. Although it will be possible to get by at least for the first time, the most important thing is that interest in this topic does not drop, and then we'll come up with something. G8)

By April 31st, the demo_ZASM_v3_10_ is planned to be released - you will see everything for yourself, but...
what has been added:
- exa=ex af,af' (c) MASM 1 G8)
- all jr, ret, call with flags are written together, i.e.:
| jr c,Label = jrc Label
| ret nz = retnz
| call nc,Proc = callnc Proc
ANDthe left and right parts are correct, but the right one is still closer to me. Ж8)

As for the rest, only directives have been added. There will be a demo - read it.

VM> That is. It’s clear that this crazy idea can be implemented on a PC. And on Spec?

VM> If it comes down to tokenizability, then, IMHO, even the
VM> assignment operator should fit well into tokens (hence,
VM> be relatively quickly assembled)

VM> TVP P TK P TK P TK P ..., where:
VM> TVP-token of the assignment expression (for, for example, LET)
VM> P-variable/constant/register
VM> TK-token of a command in an expression (assignment, math/log operation, etc.)

VM> TKs can overlap in values the codes of tokens of ordinary commands, since
VM> are found only in an expression.

VM> Still, for example, the LD command ... is also quite ambiguous, but after all you
VM> somehow cope with this :)

VM> ...And then you look, ZASM 4.0 will be released :))
1/5 of the string packaging procedure that I was preparing for ZASM 4.0 (and the idea
of which is similar to yours) is already there - it was ~10 months ago, and then we
started v3.10 ... it would be better if we didn’t do this.... Ж8)

VM> Warm greetings, Slava.

VM> -+- MS GENS'97 v2.51.A0901++
VM> + Origin: Made by Copper Feet(2:5030/461.12)