[Oberon] A2 Repository

[Treutwein Bernhard]

Dear Felix,

thanks a lot for the clarification ...

Kind regards
--
  Bernhard

>-----Original Message-----
>From: Felix Friedrich [mailto:felix.friedrich at inf.ethz.ch]
>Sent: Wednesday, July 03, 2019 9:31 AM
>To: ETH Oberon and related systems; Treutwein Bernhard
>Cc: 'Felix Friedrich (felixf at inf.ethz.ch)'
>Subject: Re: [Oberon] A2 Repository
>
>Dear Bernhard, all
>
>We are currently investing effort into cleaning up A2 (portability ...)
>and making it usable as a system with soft real-time guarantees. You
>probably know that Oberon and A2 featured a stop-the-world garbage
>collector that became more and more of an issue with larger projects.
>After having made various experiments with generational collectors (-->
>cardSet...) , we now have a reasonably simple concurrent GC. For
>processes that do not allocate memory, we have extremely short stopping
>times now.
>
>Such experiments can best be carried out with A2 being run on top of
>another OS (such as Linux or Windows). But we will make sure that native
>versions are properly supported again. It just takes time because our
>resources are very limited. We still teach Oberon in a course called
>"System Construction" at ETH and we always use the latest versions of A2
>for development and implementation. This implies that we need to finish
>this work before October.
>
>Kind regards
>Felix
>
>PS: Oberon and Gadgets did not disappear from A2. Only the native build
>excludes the respective packages in order to keep the system minimal.
>
>
>> Dear Michael,
>>
>> thanks for the invested time and work although the results are quite a bit
>disappointing.
>>
>> @Felix: Any chances for recovery?
>>
>> Regards
>> --
>>    Bernhard
>>
>>> -----Original Message-----
>>> From: Michael Schierl [mailto:schierlm at gmx.de]
>>> Sent: Saturday, June 29, 2019 10:10 PM
>>> To: oberon at lists.inf.ethz.ch
>>> Subject: Re: [Oberon] A2 Repository
>>>
>>> Hello,
>>>
>>>
>>> Am 20.06.2019 um 23:25 schrieb Michael Schierl:
>>>> When taking r7367 and using Heaps.Mod from r7366 (plus adding an empty
>>>> CheckAssignment* implementation), the system boots again. So, the triple
>>>> fault is likely caused by a change in Heaps.Mod.
>>> After some more investigation, it is only indirectly the case.
>>>
>>> The culprit is the variable "cardSet" introduced here:
>>>
><https://github.com/metacore/A2OS/commit/0dc3648ec67f89205519d3a06a41
>>> 01920bfadb97#diff-9b871273cc2a9acefd2d27c4ffe3bdf4R323>
>>>
>>> As a consequence, the size of the linked images increases by 128KB, and
>>> since the default OBL.Bin loader tries to load the linked image into
>>> conventional memory (640K ought to be enough for anybody), the image
>>> just got too large.
>>>
>>>> For r7409/r7412/r7461 there were many compile time errors I was not
>>>> quickly able to fix.
>>> Reason here was the change in
>>>
><https://github.com/metacore/A2OS/commit/b4617815d2c3b7d5ff7550baafe43
>>> d46f7bede9b#diff-3252168e91a62b6afaa2443658b703a7R1187>
>>> that changed the namespaces to be separated by dashes instead of dots. I
>>> am unsure why this broke the Bios32 build but not the WinAOS build, but
>>> since this got fixed some revisions later, probably it is not important
>>> anyway.
>>>
>>> Anyway, when reverting this change (and also reverting the change how
>>> GetModuleSegmentedName is built), these versions compile and run again,
>too.
>>>
>>>
>>> Coming back to our main goal of recompiling a recent A2 version: The
>>> linked image of recent versions is a bit over 800KB, so I assume it is
>>> unrealistic to get this stripped (without breaking the system) to fit
>>> within 640KB. There seems to be a second Boot loader (OBLUnreal.Bin)
>>> available, which supposedly tries to avoid this limitation by switching
>>> to "Unreal mode" (also known as flat memory segment hack) and loading
>>> the image into extended memory instead.
>>>
>>> However, I was not able to make this bootloader boot (on VirtualBox, at
>>> least), neither when using a current version of A2 nor when using an old
>>> version that still boots fine with OBL.Bin.
>>>
>>>
>>> So I guess, to wrap this up, the issue with recent A2 native builds is
>>> that the linked image got too large for being loaded with OBL.Bin, and
>>> the alternative OBLUnreal.Bin does not work (on all hardware where
>>> OBL.Bin worked). Probably one could spend a lot of time finding the
>>> latest version that can get stripped down to fit into conventional
>>> memory, but I don't see a point in doing that myself.
>>>
>>> Other solutions could be to either implement a self-decompressing image
>>> (so it can be loaded with original OBL.bin; but even that might be "not
>>> enough" at some point) or add support for creating Multiboot or
>>> Multiboot2 images (and load them with a Multiboot-supporting bootloader,
>>> like SYSLINUX, ISOLINUX, PXELINUX or GRUB; disadvantage being that it is
>>> no longer possible to install A2 to an empty hard disk just from within
>>> A2). But both of them are a lot more work than I'd like to spend on this
>>> (side-)project.
>>>
>>> So I will stop my A2 endeavors here - since I also noticed that
>>> OberonGadgets apparently disappeared from later A2 versions, I'd
>>> probably stick with earlier versions anyway :D
>>>
>>>
>>> Regards,
>>>
>>>
>>> Michael
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>--
>Dr. Felix Friedrich, Senior Scientists
>Department of Computer Science
>ETH Zurich, UNG F 14
>Universitätsstr. 19
>8092 Zurich, Switzerland
>tel.: +41 44 632 8312