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

[Joerg]

Chuck
yes, but file would not be portable anymore because of endianess.
br
Jörg

> Am 31.01.2021 um 16:52 schrieb Charles Perkins <chuck at kuracali.com>:
> 
> 
> 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
> --
> 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/ef8d7502/attachment.html>