TIP: Click on subject to list as thread! ANSI
echo: cis.os9.68000.osk
to: All
from: Jack Crenshaw 72325,1327
date: 1990-12-26 08:33:26
subject: #68000 ASM Language

#: 8899 S12/OS9/68000 (OSK)
    26-Dec-90  08:33:26
Sb: #68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: All

For some time now I've been tinkering with the idea of writing an assembler for
the 68000.  I'm using SK*DOS, which doesn't currently have a relocating
assembler, and we need one.  I'm also adding a disassembler to my hex debugger.

I've made several stabs at it, but I keep getting bogged down in complexity,
and I finally figured out the reason:  68000 assembly language is _AWFUL_!

Never mind the complexities in the hardware, or the fact that, having set
themselves a goal of an orthogonal instruction set, Motorola then set out to
introduce all kinds of bizarre non-orthogonalities.  That's in the hardware,
and there's nothing we can do about that.

Let's just concentrate on the assembler language.  I finally realized (I'm a
little slow, sometimes) that part of my problem is that the mnemonics are
inconsistent and irrational.  For one thing, there are cases such as ADD, and
ADDA where they chose to use separate mnemonics for what is essentially the
same instruction (with the same opcode).  [ I know, I know ... most assemblers
allow ADD for ADDA, but they still have to support both.]

Then, on the other hand, there are cases like ASL in which the same mnemonic
refers to completely different instructions, with vastly different opcodes and
argument encoding, depending upon whether we're shifting a register or a memory
word.

[More]



There are 2 Replies.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.