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

[James Jones]

In a multitasking environment, self-modifying code will cause random
failures without additional overhead to allow only one process to run it at
a time, and of course, code in ROM can't be self-modifying.

In vo-tech class I wrote some code for the RCA 301, an ancient discrete
transistor computer that did BCD arithmentic, with addressing modes so
impoverished that to do multi-digit multiplies *required* self-modifying
code to churn out the partial products just as you'd multiply on paper. One
of the goals of the 6809 was to make such tricks unnecessary; its designers
had running code in ROM as a design goal (see the three-part BYTE article).

On Mon, Jul 10, 2017 at 7:04 PM, Gene Heskett <gheskett at shentel.net> wrote:

> On Monday 10 July 2017 15:59:37 James Jones wrote:
>
> > That's what disassemblers are for, save for programs that do tricks
> > like modifying themselves.
> >
> I've seen quite a few disparaging remarks about self-modifying code pass
> by in this thread. Sloppy coding WILL bite you in the butt, so I got to
> tell you there is not a thing wrong with it if you have a good grip on
> what it is you are doing.  That code I wrote for the RCA 1802 had 6 or 7
> locations where the code was self modifying, otherwise I would have had
> to duplicate an identical string of 50+ bytes quite a few times.  The
> last thing that code did was to restore every modified location to the
> initial value.  It was dead stable, and I cannot recall there was ever
> an instance of miss-behavior after the first week it was in service.  It
> was out of service for a couple hours about a month later while I added
> a 6 volt gel-cell as a power outage UPS. The best one can say of it was
> that it "Just Worked", for 17 years that I  know of.  That was what I
> intended for it to do, Just Work.
>
> > Were I teaching assembly language, I'd show the instruction formats,
> > and then go into particular instructions as needed. Are you wondering
> > whether the order of registers in the push/pull instructions makes a
> > difference? Write assembly language that has them in different orders,
> > and see whether the generated bytes for the two instructions as shown
> > in the listing are the same. (If memory serves, they are.) About
> > span-dependent instructions, I'd point out the different encodings and
> > point interested students at the relevant paper from CACM back in the
> > 70s, (The general problem is NP-complete, but there's an efficient
> > algorithm that works for a family of displacements that includes all
> > but the most pathological examples, and a good assembler ought to
> > implement it.)
> >
> > James
> >
> > On Mon, Jul 10, 2017 at 12:38 PM, CoCo Demus <retrocanada76 at gmail.com>
> >
> > wrote:
> > > Machine language is mandatory when you are debugging or
> > > disassembling code
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>