Subject: AS80 Bug

From: "Jeff" <fyberoptic1979@...>
Date: Mon, 06 Aug 2007 15:48:51 -0000

Since I sometimes don't know for sure if a particular parameter can 
be used with a certain Z80 instruction, I just try it anyway, and 
then see if it compiles.  If I get an error, I just check the 
datasheet, and then learn from my mistake.  Well it seems that 
there's a little bug in AS80 which causes a minor issue if you try a 
particular invalid command.

Basically, if you try to use "add hl, ix", you end up with "add ix, 
ix".  Same is true for "add hl, iy", getting "add iy, iy".  I 
couldn't figure out what was wrong with some of my code, and testing 
it in a Z80 simulator revealed what was going on.  I manually checked 
the opcode bytes too to make sure the simulator might not be screwy, 
but sure enough, AS80 was generating improper instructions in those 
two cases.

Now of course, you can't actually add ix to hl, as the datasheet 
would indicate, so my code was in error.  But it obviously should 
have errored out instead of continuing on, and using a different 
instruction even.  

I tried this both in versions 1.11 (found here in the Files section), 
and 1.41 (the newest on his site), same thing.  So I contacted the 
author about it, and he said he'd fix it.  But I figured I'd point it 
out for anyone else here using that one, in case they might make the 
same mistake I did.

Speaking of bugs, I also found that v1.41 is now giving me errors 
when including a file of "db" strings (for the font I'm including 
with the code), yet if I assemble the same code with v1.11, it works 
fine.  So I dunno what's going on there.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 07 Aug 2007 23:37:57 -0000

> have errored out instead of continuing on, and using a different 

Yeah!  

I was trying to imagine just how this kind of mistake could 
happen.  I mean, does as80 actually have "add hl,ix" in a table
of opcodes???  I'll bet it doesn't.

All of the ix & iy instructions use same opcode as the
coresponding hl instruction, except there is an extra byte
in front that tells cpu to use ix or iy instead of hl.

So, probably when as80 sees an ix anywhere in an instruction,
it emits the ix prefix byte, and then converts the ix to hl,
and assembles it as an hl instruction.  But it needs to check
if ix is allowed in that position first!!!

A "DD" in front means use ix instead of hl, and "FD" means
use iy.  I don't think there are any valid instructions with
both hl and ix, or hl and iy, and I guess that also means you 
can't have both ix and iy either.  And not all insts that can
use hl can substitute ix (or iy).  

"ex de,hl" is valid, but "ex de,ix" is not.  AS80 does
catch that!  So much for my earlier theory...

> author about it, and he said he'd fix it.  

That's great!  And it's good to know it is still being maintained.

I remember finding a bug in a 6805 assembler that I downloaded
directly from Motorola.  I was finding lots of "lost clusters"
on my hard drive, but I had no idea why.  Windows would crash
for some totally unrelated reason, and when it rebooted and
checked the disk, it told me it was finding lost clusters.
Most of the time, it was not the program that crashed that
had lost them, or even any program that I used that day.

Of course, windows would crash quite often, and not find any
lost clusters.

After many frustrating weeks, a pattern emerged: I had used
the motorola assembler recently.  I tested theory by using
chkdsk before and after, and sure enough, EVERY TIME I ran
it, I had lost clusters.

Oh wow!  I found a bug in Motorola's assembler!!!  I
called them up (this was a long time ago) and told the
"tech support" guy.  Turns out they knew about it already.
Turns out they knew about it for quite a while.  Like 3 or 
4 years.  Turns out, they even had documented it, deep down 
in a part of the doc that most people would never need to read.

I guess I'll just have to imagine how good it felt to hear 
back that he was gonna fix your bug.  :-)

(Oh yeah, right around that time Philips had a design contest 
where you could get their software and chip programmer for like
$30 bucks.  I haven't used any Motorola parts since.  Are
they even in business anymore?)

> But I figured I'd point it 

What kind of error?  Does it work if you paste the file in,
rather than include it?  Or, is it a difference in handling
of the "db" itself?

--CJ

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Tue, 7 Aug 2007 17:32:41 -0700

On 8/6/07, Jeff <fyberoptic1979@...> wrote:
> datasheet, and then learn from my mistake.

Clearly you've never used a Forth assembler :-)

-- John.

---

From: "Jeff" <fyberoptic1979@...>
Date: Wed, 08 Aug 2007 00:56:08 -0000

--- In [email-masked], "Cyrano 
> chkdsk before and after, and sure enough, EVERY TIME I ran

I can only assume that they wrote the assembler in assembly as well, 
because it seems kind of unlikely to have such a problem from using 
higher level language, as far as I can tell.

Sounds like that was back in the pre-Win2K days though, when Windows 
would actually let you destroy and mess up things without stopping 
you.  These days most everything's all sandboxed (in the case of old 
DOS apps), or usually only accessable via the Windows API.  But 
luckily people sometimes come up with ways to still interface with 
hardware, such as the DLLs to write to I/O ports, letting me talk 
directly to the parallel port and such.

There's still a charm about being able to still have that level of 
hardware control, though, which is why I still keep Win98, as well as 
Linux, on my laptop (and XP for when I actually want to use Windows 
productively).  I was working on some raw floppy drive controller 
routines in assembly once and was using Win98 to test'em, especially 
since it also let you drop straight into DOS mode.  Though this was 
also about the time I realized that using floppy drives in projects 
was a crazy idea, when compact fash and SD were much easier to deal 
with.  And CF is basically 8-bit IDE even, so interfacing a full hard 
drive would still be easier than a floppy.

> in a part of the doc that most people would never need to read.

Yeah there's a level of disappointment to think that you've 
discovered something only to find out that it was found long before.  
But in that case, it's even more disappointing to think the company 
would sit on it that long without bothering to fix it.  Especially 
when you pretty much need it to use their products!

> Are they even in business anymore?

Surprisingly so, after what you said.

> rather than include it?  Or, is it a difference in handling

It pretty much tells me "Redefinition of label" for every label 
following the included file.  It didn't used to do this though; it 
wasn't till my main file got bigger that it complained.  It also 
looks kind of odd, writing over some of the output text when it puts 
out these errors.  Like how it'll say stuff like "Reading line 500" 
and whatnot, you know.  It starts spitting the error text out on top 
of it, instead of under it like a legit error.

I tried what you mentioned though, and strangely enough, it compiled 
just fine when the data was added into the main file.  I didn't 
really have enough info to go on to report this one to the fellow, 
but I think this might be enough to help him track it down to the 
'include' option somehow.  I'll let him know the symptoms.  I'm sure 
he'll feel overjoyed to be hearing from me yet again.  ;)

---

From: "Jeff" <fyberoptic1979@...>
Date: Wed, 08 Aug 2007 00:57:44 -0000

--- In [email-masked], "John R. Hogerhuis" <jhoger@...> 
> Clearly you've never used a Forth assembler :-)

lol I haven't, in fact!  Should I take it that they weren't very 
forgiving?

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Tue, 7 Aug 2007 19:06:03 -0700

> lol I haven't, in fact!  Should I take it that they weren't very

In Forth you just execute word after word. Either it's a number and it
goes on the stack, or it's a subroutine and it runs, consuming values
from the stack, possibly putting some back on.

So a Forth assembler typically has constants that represent the
operands. These end up as values on the stack.

SO

H   L   MOV,

MOV, pops the values pushed by H and L constants, Or's them together
with its base opcode, and appends the resulting instruction byte to
the dictionary.

Try some random combination of operands that it doesn't expect, and
hilarity ensues. It will put something in the dictionary, probably not
the instruction you expect though...

-- John.

---

From: "Jeff" <fyberoptic1979@...>
Date: Tue, 14 Aug 2007 20:36:32 -0000

The fellow took care of all the bugs I stumbled across and released 
v1.42 on his site, for anyone that wants to grab the newest:  http://
www.kingswood-consulting.co.uk/assemblers/

That includes the "ADD HL, IX" bug I mentioned in my initial post, a 
bug that was occurring when 'include'ing files larger than 8KB, and 
an 'align' issue which was adding in more padding bytes than 
necessary.  It works like a charm for me now.

He apparently supports several other processor types too with 
different versions of his assembler, such as 6502, which is cool.  If 
he made an 8052 version, I'd likely use it too!