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

[Jörg]

Right. Look at ORG.CopyString then you know why…..

Jörg

 

From: Oberon <oberon-bounces at lists.inf.ethz.ch> On Behalf Of Charles Perkins
Sent: Saturday, January 30, 2021 9:23 PM
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Why is RSC string data word-aligned?

 

Just an intuition, but 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, simplifying assignment (copying) and comparison.

 

On Sat, Jan 30, 2021 at 12:12 PM Colby Russell <oberon at x.colbyrussell.com <mailto:oberon at x.colbyrussell.com> > wrote:

I'm returning to some of the code that deals with Oberon's RSC binary
file format.  The first time I went through this exercise, I noticed
that ORG pads string data, so individual strings begin on word
boundaries, and I didn't think much about it.  Presumably it was done
for efficiency.  Now, though, I'm wondering.

Does anyone have a breakdown comparing the two approaches--where strings
don't get padded with NUL bytes and may begin anywhere, versus what
happens if with word alignment?  If there are some string handling
routines where this makes a material difference, can someone point to
them?

I've already looked around, but I realize that string representation is
a cross-cutting concern, and there's just too much material to
exhaustively scour it all again.  If there was a call out on this topic
in the explanation of the the simple compiler that's documented in
Compiler Construction, then I wasn't able to find it.  I looked at a few
sections in the Oberon book as well, hoping to see if it was explained
(e.g. the module loader chapter), but didn't spot anything there,
either.

-- 
Colby Russell

--
Oberon at lists.inf.ethz.ch <mailto: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/20210130/ef8b2132/attachment.html>