[Coco] Linville's ramblings on assembly vs machine code

[Brett Gordon]

Difference between machine code and assembly is an assembler.  If you think
the complexity of an assembler is trivial then there's little difference!

I dare all to make an assembler in machine code, then report to us the
sameness... ;)

brett

On Jul 10, 2017 3:25 AM, "Dave Philipsen" <dave at davebiz.com> wrote:

> Ok, so the list seems rather quiet so I'll try to stir the pot a bit
> here.  On the CoCo Crew Podcast John Linville rambled on for about nine
> minutes telling us how machine code is essentially the same as assembler
> and there's no reason to even try to learn it as it's simply a different
> (and more difficult) way of 'saying' the same thing.  His reference was to
> a question posed by John Mark Mobley on 5/31 at 11:52 AM.
>
> I am in agreement with part of what John said.  That is, that machine code
> and assembler are essentially just different ways of 'saying' the same
> thing.  However, John went on to say that you're already cool if you know
> how to code in assembler and you don't have to show how macho you are by
> entering in the raw data which is representative of the assembler mnemonics.
>
> First, let's look at John Mark's original question: How do you practice
> simple machine code on a CoCo.  (?) This is just to teach the basics of
> machine code as an introduction to assembly. What steps should one follow
> to practise machine code. (?)  Note that John Mark mentioned that this was
> just to teach the 'basics' of machine code as an 'introduction' to
> assembly.  It's not a full blown course on how to write a huge piece of
> code entirely in machine language.
>
> In my personal opinion, I can see why an instructor would want his
> students to at least get a taste of how entering raw numerical data as
> 'machine code' actually works.  It's certainly not necessary to memorize
> all of the hex (or octal or binary or decimal) codes that represent all of
> the processor opcodes with all of their different addressing modes.  That
> would be ridiculous (and difficult)!  But, seeing how machine code differs
> from assembler gives you an eye into how the CPU actually works.  Here are
> a couple of examples:
>
> I was talking with someone once about pushing and pulling registers
> to/from the stack on the 6809.  He had a concern about how one particular
> disassembler represented the order in which a list of registers would be
> pushed or pulled.  From the point of view of someone who worked purely with
> assembly mnemonics and never even bothered to look at the machine codes
> that had been assembled, this might be a valid question.  Does it matter
> how you order the registers when you push or pull them? (i.e. is pshs
> a,b,x,y different than pshs y,x,b,a ?)
> If when you learned assembler you at least got a taste of how it relates
> to machine code you would know right away that it matters not because each
> of the registers to be pushed or pulled is represented by a single bit in a
> post code byte that follows the opcode.  The processor will always push or
> pull the registers in the same order regardless of how you write it in
> assembler.  So to answer the question: no, pshs a,b,x,y is not any
> different than pshs y,x,b,a.
>
> Another example might be when using the load effective address
> instruction.  Why is the construction of leax 1,x any different than leax
> 100,x?  Again, a person who is only familiar with the assembler mnemonics
> would not necessarily understand that the former needs one post byte while
> the latter needs two.
>
> The same might be true with bhi and lbhi.  A person not familiar with the
> machine codes might wonder why there is even a differentiation between
> branches and long branches.  Why not just write them all as long branches?
> A good book on assembly language (like Lance Leventhal's) will explain
> why.  And when it explains why, you are actually delving into machine
> language.  Now you understand why long and short branches are necessary and
> why stack order is not important.  In fact Leventhal's book could have been
> entitled '6809 Assembler Language Programming with machine code examples'!
>
> So, yes, it doesn't make much sense to 'learn' machine language or code
> with it.  But, it makes a lot of sense to understand it fundamentally.
> This becomes even more necessary when you are doing any of the following:
> 1) programming in an environment where the amount of memory is severely
> limited, 2) programming something that can only be accomplished in
> assembler/machine code because of timing and/or speed issues, and 3)
> working in a target environment where an assembler is not available.  The
> last issue, number 3, may be when you use a machine to assemble code that
> ends up in an embedded device that has neither a mass storage device nor
> enough memory to run an assembler.
>
> Many of us have written assembler code that runs on our CoCos, Commodores,
> Apples, etc. but have never written the same type of code (6809, 6502, Z80,
> etc.) to run on another target with limited resources.  Those of us who
> have will tell you that it is very beneficial to at least have an
> understanding of machine code and how it works.
>
> Most of us, however, know the difference between the word "can't" and the
> expression "can not" (or cannot).  Even though they all mean the same thing
> I think that you would consider yourself better educated for knowing the
> difference.
>
> Dave
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>