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

[John Guin]

Ah, for the good old days that the CPU ran the instructions in the order the human wanted.  Intel has a feature that re-orders instructions if it thinks it can run faster, especially when moving data into/out of registers: http://preshing.com/20120515/memory-reordering-caught-in-the-act/

I actually hit this recently at work while debugging a routine to compute kurtosis.  To Intel's credit, they offer an SDK that shows the actual instruction order the CPU will process, but I did not purchase that tool.  

It really amazes me at how seldom the re-ordering needs to be correct to actually run faster - about 11% success rate is enough to see a speed boost, if memory serves.

John

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Salvador Garcia via Coco
Sent: Monday, July 10, 2017 9:37 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Cc: Salvador Garcia <salvadorgarciav at yahoo.com>
Subject: Re: [Coco] Linville's ramblings on assembly vs machine code

In a few words, I agree with you Dave.

A programmer does not have to know ML to program in ASM, but knowing it will make him or her a better ASM programmer..

I liked your push/pull and short/long jump examples. Knowing how the push and pull instructions are represented, a programmer does not need to waste mental energy wondering which register should come first or last. Knowing how the short and long jumps are different can be the difference between code working or not working within an ISR.

Salvador



On Monday, July 10, 2017, 2:25:42 AM CDT, 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

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco