[Oberon] RISC5

Sun Apr 20 22:35:02 CEST 2014

There is no source to module SYSTEM.  It is a compiler trick.

This sort of trick is used extensively in unsafe languages such as C, and
it is a tribute to the safety of Wirthian languages that it disturbs you
when it is expressed in Oberon, and that it is clearly marked as a trick.

To know how the author selected this code, you have to look at the
documentation.  That documentation is slightly different with each release,
such as Oberon V4, Oberon S2, the RISC version, and Blackbox.

I think your interpretation of the meaning is correct, it is an assignment.
 I don't know which is the source and which is the destination without
looking at the documentation for SYSTEM, and cross checking it with PPP
documentation to be sure that both the interpretations that I have agree.
 You should be able to do that on your system.  You will look for some
large document, such as Oberon.Text, that will have a chapter on low level
compiler extensions.

On Sun, Apr 20, 2014 at 11:33 AM, eas lab <lab.eas at gmail.com> wrote:

> 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
> >
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20140420/29149d54/attachment.html 