[Oberon] A2 Repository
Felix Friedrich
felix.friedrich at inf.ethz.ch
Wed Jul 3 09:30:57 CEST 2019
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
More information about the Oberon
mailing list