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

[CoCo Demus]

Machine language is mandatory when you are debugging or disassembling code

On Jul 10, 2017 2:23 PM, "John Guin" <johnguin at hotmail.com> wrote:

> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>