[Oberon] RISC5

[eas lab]

Here's an extract from PPPMain.Mod:

TYPE PhysAdr = ARRAY 6 OF SYSTEM.BYTE;
  SYSTEM.MOVE(SYSTEM.ADR(item.data(*.data*)[24]),
              SYSTEM.ADR(item.data(*.data*)[14]), NetIP.AdrLen);

 item.data[24] is a RECORD.Field:array:element in another Module.
so I can work out that N-bytes are being moved from Source to
 destination. And N is probably related to NetIP.AdrLen.

But where did the author select this instruction from?
Watson doesn't show the exports of SYSTEM-module.

== Chris Glur.


On 4/18/14, Aubrey.McIntosh at alumni.utexas.net
<Aubrey.McIntosh at alumni.utexas.net> wrote:
> IMPORT SYSTEM
>
> is a directive to the compiler so that it can do unsafe things.  All of the
> procedures are documented in the documentation that comes with the system.
>  These are things like type coercion, bit shifts, and a few other very low
> level things that are done when talking to the hardware.
>
> I think it is very open.  It is documented everywhere, and has been part of
> Wirth's languages for a long time, possibly as early as Modula-2.
>
> It's primary purpose serves documentation and safety.  The compiler will
> not emit tricky code unless SYSTEM is in the import list, and you can
> quickly search for the string "SYSTEM" + "." to locate everywhere in the
> source where these tricks are used.
>
>
>
>
> On Fri, Apr 18, 2014 at 11:05 AM, eas lab <lab.eas at gmail.com> wrote:
>
>> Thanks for the pointers.
>>
>> Today I tried to trace the M.P route of how eg. ET.* gets to the
>> VGA-port.
>> [Like you CAN trace how http* arrives via a serial-port-modem ...etc.]
>> For ETH Oberon (2.4.3) for Linux x86   and
>> V4/oberon-1.7.02/Source  and my
>>  source1, 2, 3.arc  which I guess comes from Native;
>> in all cases the path is concealed at: IMPORT SYSTEM.
>> Some of us resent that. Oberon may have had a better following if
>> it had been open. OTOH perhaps that was not possible?
>>
>> == Chris Glur.
>>
>>
>> On 4/17/14, Jörg <joerg.straube at iaeth.ch> wrote:
>> > Chris
>> >
>> > 1) The RISCv5 machine has a memory of 1 MByte = 000000H.. 0FFFFFH.
>> >    This memory is used to hold your code and store your variables.
>> >    A dedicated region at the high end of this memory (namely from
>> >    0E7F00H .. 0FFF00H) is called "framebuffer"; this memory region
>> >    is used to store all pixels that are displayed on the screen.
>> >
>> > 2) The module "Display.Mod" provides all low layer routines to
>> >    store pixels into this memory region. E.g. the procedure
>> >    Display.Dot(col, x, y, mode: INTEGER) "draws" a dot at location
>> >    (x/y). But it does not actually draw the point but "just" stores
>> >    a bit in this dedicated "framebuffer" memory.
>> >
>> > 3) In parallel, the video driver "VID" (written in Verilog) permanently
>> >    reads this special framebuffer memory and copies all bits over and
>> >    over again to the VGA monitor. The whole framebuffer memory
>> >    (96 kByte) is copied 70 times per second to the monitor.
>> >
>> > Hope this helps.
>> >
>> > br
>> > Jörg
>> >
>> > -----Original Message-----
>> > From: Paul Thomas Melville [mailto:ptmelville at gmail.com]
>> > Sent: Donnerstag, 17. April 2014 13:46
>> > To: ETH Oberon and related systems
>> > Subject: Re: [Oberon] RISC5
>> >
>> > On Thu, Apr 17, 2014 at 10:58 AM, eas lab <lab.eas at gmail.com> wrote:
>> >
>> >> The hidden/mysterious part for me is the display/textFrames.
>> >> Does V5 drive standard VGA?
>> >> Where's the code showing;
>> >>   VGA -> FrameBuffer -> ETHOviewer.
>> >
>> > You can find information in section 9.1, 4.5 and 17.2.4 of Project
>> Oberon.
>> >
>> > --
>> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>> > systems
>> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> >
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
>
>
>
> --
> Aubrey McIntosh, Ph.D.
> 211 E. 5th St.
> Morris MN 56267
> (512)-348-7401
>