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

[Colby Russell]

Copying my orginal response to Charles here, because I forgot to reply
to the list.

On 1/30/21 2:23 PM, Charles Perkins wrote:
 > if string constants and string variables start on a word boundary and
 > are padded with nul to a word boundary then a number of string
 > operations only require word access

That's my intuition as well, but that's what I'm trying to verify. I'm
trying to track down some specific, concrete examples where we can see
that the cost of not having padding is higher than the cost of dealing
with a string with padding.  Operations like printing a string, for
example, are what I have in mind.  If you have a 5-character string,
word alignment means you can get the full contents in 2 memory accesses,
but the operations are still going to be occurring at the byte level...
So where are the savings?

On 1/30/21 3:16 PM, Jörg wrote:
 > Right. Look at ORG.CopyString then you know why

ORG.CopyString operates on ORG `Item` objects representing in-memory
strings, not the binary data contained within an RSC file.  By the time
the generated code is executing, the module's string section has already
been read from disk by the module loader--which happens a single
character at a time.  Viz:

<https://hypothes.is/a/Wx_nmmNEEeuHEi-6X3lPnQ>

It appears this is an (unnoticed?) opportunity for further optimization
of the Oberon system.  The caveat being that it constitutes a breaking
change to the RSC file format.  So perhaps Wirth has noticed and just
decided that it wasn't worth the trouble?

-- 
Colby Russell