[Oberon] Numerical CASE Statements in Project Oberon
Jan de Kruyf
jan.de.kruyf at gmail.com
Tue Nov 24 19:38:57 CET 2015
John, thats a complex matter really.
Anything we dont know at compiletime is left dangling for resolving 'later'.
Part of that 'later' is resolved by the linker, in Linux or Windows. And
still more is resolved when the code gets loaded.
In Oberon, in general there is no linker, except when we want to build some
boot-code.
Everything not known at compile-time must then be fixed up when we load the
module. And to complicate matters, some choices are made by the system
designer about what we actually _want_ to know at compile time. It is
basically a cost / benefit choice, sometimes it is easier to leave the
complete solution until load time, although at least part of the knowledge
was available at compile-time.
In the case I queried I did not see a reference to the index register that
LDR uses. That space as left at '0' to be patched at load-time (so it
looked as if R0 was to be used for an index), although R12, the standard
index register, could have been written there at compile-time for my
specific code.
Section 6.3 gives some small introduction to the art of loading. Near the
end of the page is the line:
"At the very end of the file three integers called fixorgP, fixorgD, and
fixorgT are read."
That is where he talks about the patching.
>From the code in Modules.Load and from the compiler description it follows
that globals need to be treated specially, since they might come of any
module. So although we might have a partial knowledge of the place of a
'local' global at compile time, it is obvious that we don't know at all
about globals in other modules. So Wirth chose to fix them all in one
place: the module loader.
In any case: a good way to learn compilers is to target a small micro
controller that you know very well, and adapt the Oberon 0 compiler. I have
done it many years ago for an 8 bit AVR, and it has helped me ever since.
Cheers,
j.
On Tue, Nov 24, 2015 at 1:22 PM, John Stout <JSS at kgv.ac.uk> wrote:
> Jan
>
> Yes, that's the one although my copy is on faded line printer paper!
>
> I'm interested in your email about code generation: what does Module.Load
> patch and to what?
>
> I've just bought an OberonStation and am getting to grips with it. I think
> the first task is to get another nRF24L01+ system working so that I can
> transfer stuff to and from it.
>
> John
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Nov 2015 12:09:45 +0200
> From: Jan de Kruyf <jan.de.kruyf at gmail.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon
> Message-ID:
> <CAA85NCh6R8Xf-Tp53sFF0=
> F_5rnH7WXoeTyeDQss-eDMsVMaLg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is it this one John?
>
> http://homepages.cwi.nl/~steven/pascal/
>
> There are links there to a 76 version from eth.
>
> j.
>
>
> On Mon, Nov 23, 2015 at 9:47 AM, John Stout <JSS at kgv.ac.uk> wrote:
>
> > Well, I should have done a bit more research before making my comments,
> > and/or done all the exercises in Compiler Construction, which would have
> > lead me to Professor Wirth's preferred implementation for CASE.
> >
> > I have the source code for the Pascal P4 compiler from 1976 (courtesy of
> > Lancaster University) and that uses this system, although it does place a
> > maximum of 1000 on the number of cases.
> >
> > John
>
> [King George V Logo]
> John Stout
> Management Information Systems Coordinator
> Tel: 01704 530601
> E-Mail: JSS at kgv.ac.uk
> Web: www.kgv.ac.uk
>
>
> Information contained in this e-mail is intended for the use of the
> addressee only and is confidential. Any dissemination, distribution,
> copying or use of this communication without prior permission of the
> addresseeis strictly prohibited.
>
> Every effort has been made to ensure that any attachment to this mail does
> not contain virus. King George V College has taken every reasonable
> precaution to minimise this risk, neither it nor the sender can accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry outyour own virus checks before opening any attachments.
>
> [Think Before You Print]
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151124/eb8b6048/attachment.html>
More information about the Oberon
mailing list