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

[Gene Heskett]

On Tuesday 11 July 2017 05:51:58 James Jones wrote:

> 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).

The most impressive advance the 6809 gave us was PCR code. With that, 
code did not have to be rebuilt if its address in rom was changed. To 
me, that gave the motorola offerings that included it, several steps up 
the ladder of capability.

I do know that the intel stuff had to be patched to achieve that effect 
when loaded into memory from rom, causing the loader to need to apply 
the patches and to need 10% more rom than the loaded code looked like in 
memory.  But I've always thought that road had so many potholes it was 
sure to go down in flames, and early versions did often enough to 
confirm my suspicions.

If there were patents on it which I'm uninformed about, that would 
preclude its use by others until moto was either bought to gain access, 
or the patents to expire before it would become common useage. But I'd 
suspect nearly all cpu's can do it today.

The singular feature I missed in programming the 6x09, is DMA.  Even the 
zero power RCA 1802-4-5 had it, and that meant the digital display was 
hugely simplified. I first tried a clock chip, which worked but a dispay 
that could be read from a 5" b&w monitor from 15+ feet away was needed.

That led me to use the 4 to 16, the 74154 IIRC, with a 4x subcarrier 
counter with a 4 bit output, and a bunch of small signal fast diodes, to 
generate the display. I chose the line counter so that the characters 
were 103 lines tall on the usual 262.5 tall NTSC display. The actual 
display data, which this circuit scanned twice per horizontal line, with 
the 4 bits obtained from the current byte, swapped from high nibble to 
low nibble at the center of the screen, so the end result was a 2 digit 
display that only needed 6 bytes of DMA per vertical field to generate 
it. The decimal point was hard coded in hardware for line 100 to line 
103. The 6th and last byte was $00 of course which turned the display 
off.

s100 bread board and chips + diodes might have cost $30 at the time. 
There wasn't anything else it could do, but it did that job very well. 
The 1802 executed the whole thing per vertical scan line. I put a flag 
byte in to toggle something I could time, and found the 1802 was back to 
waiting on the next falling edge of house vertical synch to start all 
over by the middle of line 21. That meant it had no trouble keeping up, 
so I was quite pleased.

> 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


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>