[Oberon] Why is RSC string data word-aligned?

[Charles Perkins]

I think the source of the cognitive difference between .rsc files and in
memory structures is that the .rsc file is a sequence of data read and
written using the file reader and writer abstract data type, while the
in-memory structures are records and arrays of values and blocks of code
with constraints applied by the compiler.

In Linux and many other Unix-based systems the structure of values on disk
(e.g. behind the file ADT) is conflated with the in-memory representation
because it can be memory-mapped (an excellent trick enabling many
performant optimizations) entirely bypassing the encapsulation provided by
the ADT.

If we were to adjust the .rsc file for word alignment of strings, making
the on-disk layout of values no longer agnostic to in-memory layout of
data, I would go much further. I would make the on-disk layout exactly the
same as an in-memory layout, enable demand paging of disk blocks to memory
locations, just page in executable code as necessary (don't need an mmu for
that if you start out by filling all page cache locations with an
instruction that jumps to the 'paged out' handler) etc, etc, etc. but that
is a much more complex system unsuitable for illustrating the core concepts
of a single-user interactive workstation.

My two cents.
Chuck

On Sun, Jan 31, 2021 at 7:14 AM Paul Reed <paulreed at paddedcell.com> wrote:

> On 2021-01-31 10:11, Andreas Pirklbauer wrote:
> > Isn’t any data - including string data . already word-aligned in the
> > compiler (and therefore also in the .rsc file)?
> ...
> >     - All type descriptors are word-aligned (see ORG.BuildTD)
> ...
> >     - All strings are word-aligned (see ORG.MakeStringItem)
>
> Right, there are sections which *would* be (file) word-aligned, if other
> previous sections weren't variable (byte) length.
>
> Cheers,
> Paul
> --
> 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/20210131/54112689/attachment.html>