[Oberon] High-level language vs assembler

[eas lab]

OK, some V4 code was the nearest example:--
codebase := S.ADR(m.code[0]);
   dummy := pthreadMutexLock(S.ADR(critRegion));
   WHILE i <= N DO
      ptr := S.VAL(FreeBlockPtr, A[i]);
      WHILE ptr # NIL DO
         INC(avail, ptr^.size); ptr := S.VAL(FreeBlockPtr, ptr^.next)
      END;
      INC(i)
   END;
----------
It is of course MUCH simpler/better than asm, especially when hiding the
 *SYSTEM*.  It's been decades since I used an assembler, but they obviously
also have <symbolic identifiers>.

Having Oberon return the value of the byte pointed to by Adr(Pointer),
is not the same as generating the corresponding machine-code, suitable
for eg. a video-driver.

I used to wiring-pen-build 8-bit Uprocs, which I programmed via my P-code
interpreter. The PASCAL-like source code could do anything, but only at
VirtualMachine speed.

Then I threw-together an assembler [written in my same old PASCAL] which
directly translated the 68xx instructions from a
 rA+rB ->rB
type syntax.

I don't remember why. Perhaps it was to make the P-code interpreter, for the
68xx VM, programmed by the orginal Z80 system from Microsoft, which came on
a cassette and an A4-sized-pages pamphlet. M$ had copied NW's ver0 straight
out of the book. Rather than the recursive-descent compiler, I prefered my
read-and-translate the railway-diagrams version, which I orginally built
to drive instruments, via a HP-desktop-calculators, which had only a BASIC
type syntax. At the time, PASCAL was a fad, and a BYTE article-series
had an implementation in BASIC; from which I was able to see that eg.
'when the train went past' CONST, it had to get ready to create the
symbol-table-entry....

== Chris Glur.


On 10/22/14, Chris Burrows <chris at cfbsoftware.com> wrote:
>> -----Original Message-----
>> From: eas lab [mailto:lab.eas at gmail.com]
>> Sent: Wednesday, 22 October 2014 10:14 AM
>> To: paulreed at paddedcell.com; ETH Oberon and related systems
>> Subject: Re: [Oberon] High-level language vs assembler
>>
>> But trying to force asm-concepts into an Oberon-like notation, eg.
>>  SYSTEM.Memory(SetSpeedReg, 47)
>> feels like useing prose to replace musical-notation, or maths-
>> formulars.
>>
>> Yes, there's no need to keep the now inappropriate original notation
>> of
>> the 60s: "mov R8,47".      I suggest
>>   #47 -> R8
>> conveys the concept, in a minimalist/most-economic way.
>> But this is all about cognitive science...I guess.
>>
>
> Whichever notation you prefer is inconsequential. The mental effort
> required
> to reliably and efficiently manipulate register usage and memory locations
> is a task much better performed by machines than humans. This is
> particlarly
> so with RISC designs with 16 or more registers at your disposal.
>
> The SYSTEM-type facilities allow you to perform low-level ASM-like
> operations on high-level structured data items without having to manually
> juggle with registers and keep track of absolute addresses.
>
> Regards,
> Chris
>
> Chris Burrows
> CFB Software
> http://www.astrobe.com
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>