[Oberon] Module Fonts without reference to SYSTEM

Michael Schierl schierlm at gmx.de
Sat Sep 5 13:32:45 CEST 2020


Hello Andreas,


Am 04.09.2020 um 22:04 schrieb Andreas Pirklbauer:
> Extended Oberon has a module Fonts that does not access module SYSTEM
> at all. I have been asked to provide one for Project Oberon 2013 as well.
>
> Below is one way to do it. It used ORD for pointers (undocumented feature).

So now you have a module Fonts that does not import SYSTEM, yet is not
portable (relies on platform-dependant things).

I played with OBNC a bit in the last weeks, and it supports a system
configuration where POINTER size is 64-bit but INTEGER size is 32 bit.
It is quite useful for a "blob-less" bootstrap of the ORP compiler (see
my Pull Request to Peter de Wachter's Project Norebo at
<https://github.com/pdewacht/project-norebo/pull/1>). In this
configuration, SYSTEM.ADR, SYSTEM.GET and SYSTEM.PUT are unavailable
(for obvious reasons) but ORD presumably is. I did not test this, but I
presume ORD would return the lower bits of the pointer in this scenario.


In my opinion, the "proper" way of a portable Fonts module would require
some more changes:


Have an empty marker type Display.PatternHolder, let Fonts import
Display and Fonts.Font be a type extension of Display.PatternHolder.

Change Fonts.GetPat (and preferrably rename it as well) to return the
address relative to the start of the Font/PatternHolder record.

Provide a Display.CopyPatternFromHolder that takes a PatternHolder, an
address, and the rest of the current parameters and uses SYSTEM.ADR (as
Display needs to import SYSTEM anyway) to do the unportable magic.

Change all the callers of Fonts.GetPat (GraphicFrames, Graphics,
TextFrames, and maybe other modules you may have written).


However, this not a small change and intoduces some more complexity to
ths system. And one may argue that Fonts should be non-portable so that
it could for example invert the bit order at font load time (in case the
native display addresses the pixels in the opposite order) instead of
having Display.CopyPattern do it each time.


Regards,


Michael


More information about the Oberon mailing list