[Oberon] Why is RSC string data word-aligned?
chris at cfbsoftware.com
Sun Jan 31 02:19:46 CET 2021
> -----Original Message-----
> From: Colby Russell [mailto:oberon at x.colbyrussell.com]
> Sent: Sunday, 31 January 2021 10:55 AM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Why is RSC string data word-aligned?
> On 1/30/21 5:44 PM, Chris Burrows wrote:
> >> Colby Russell
> >> Sent: Sunday, 31 January 2021 8:22 AM [...] >>
> >> 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?
> > I checked a couple of the compiler modules (ORP and ORS) and the
> number of > nulls in strings in the object file is about 1% of the
> total file size
> I don't mention is as a concern for file size, but as I mentioned in
> the Hypothesis annotation, as a matter of efficiency. The choice to
> align on word boundaries is (presumably) for reasons of efficiency.
> But by doing the alignment in the object file itself rather than in
> the module loader, whatever efficiency is sought is surely
> overwhelmed by the fact that many more cycles are wasted by the
> spurious character reads than the number of cycles saved, no? Every
> padding byte in the object file results in more time spent in the
> read loop and extra calls to `Files.Read`, slowing down the module
Sure - I got that. However, the whole object file is read in when the module is loaded. Hence, the module loader is only slowed down by 1% because of those extra nulls. Even on my 25 MHz RISC5 system hardware, module loading appears to be instantaneous so any gain would not be noticeable. Remember also that in Project Oberon, a module only ever has to be loaded once between reboots unless you have manually unloaded it.
More information about the Oberon