[Oberon] FPGA RISC memory interfacing

[Michael Schierl]

Hello Wojtek,
Hello Andreas,


Am 23.12.2019 um 19:52 schrieb Andreas Pirklbauer:
>     > I noticed that Oberon System frequently freezes on one Pepino which we
>     > have. I have not identified any pattern. Sometimes it works for days, and
>     > sometimes it freezes after a mouse click on a command like the Hilbert curve.
>
> It could also (potentially!) have to do with module unloading.


In my experience it is more likely that a "random" hang is caused by
failed memory allocations than by module unloading (but perhaps I unload
modules less frequently than Andreas). It can easily happen when you try
to pass too many modules to ORP.Compile at the same time. These failues
are often not explicitly handled, resulting in a TRAP. And the TRAP
handler tries to write its message into System.Log, resulting in
potentially more allocations, resulting in a "double TRAP". Since double
traps are not explicitly handled, the system appears frozen then.

There was also is a bug in the allocator (dubbed "memory alligator" here
on the mailing list), which I am not sure whether it is already fixed in
the official sources. A failed allocation can cause the linked list of
free memory segments to get corrupted, which may result in a freeze or
other corruption related artifacts later.

While the second issue is easy to fix, the first one requires a bit more
changes (e.g. detecting double trap and make it defer printing the trap
information to after the next GC cycle, or having "sacrifice memory"
allocated that gets deallocated just before the TRAP handler prints its
information).

Another (less likely) cause of freezes or memory corruptions could be a
stack overflow, which will cause the stack to overwrite parts of the
modules space. As the RISC5 CPU does not support memory segmentation or
guard pages, I assume this would be the hardest to fix. The only way I
can think of is storing the stack limit at some fixed memory address and
emitting check code by the compiler whenever the stack pointer is
reduced, which will have a noticable runtime penalty.

Or just be careful when doing recursion to not cause stack overflows :-)


Regards,


Michael