[Oberon] A Linker.Mod for an almost self-hosted RISC Oberon

[Charles Perkins]

> | Meanwhile Linker.Mod (in oberon-risc-ethz) allows OberonV5 (2013) for
> | RISC to compile its own boot track from source code to a binary file,
> | making the system almost self-hosted. An additional tool (such as 'dd'
> | on the host) is required to install the boot track.
> ---
> I'm particularly interested in booters.
> Why does even rPi tie itself to DOS: <Intrp N = reads sector X to mem:M
> and executes it> ?
> Is eg. Mac & Android locked to this standard too?
> 
> Why do you call it "Linker.Mod"?

I considered calling it MakeABootTrackForRISCV5FromCompiledModuleFiles.Mod 
but that exceeded the module name size limit. So instead, since it links modules, I 
called it 'Linker.Mod'

> If it is a booter, it must 'match its native-hardware'.

Yes, this version of Linker.Mod only creates a boot track for the (real or emulated)
RISCV5 system. It would be wonderful if it were adapted or extended to create
native boot tracks for other hardware-- the Raspberry Pi for example, or
the ubiquitous Intel architecture or perhaps the Nexus 7 tablet.  

Such a linker would require a matching compiler for the CPU architecture of each 
platform of course, and the Files.Mod, FileDirs.Mod, Kernel.Mod, and Modules.Mod
(at least) would have to be adapted.

It is a non-trivial amount of work. Volunteers?

> So if it's for a PC, the REAL native-hardware is the X86's reset-prog-counter,
> to run the ROM-BIOS, which reads the first track/sector of the boot-hardware:
> fd0, USBstik, CD...etc.
> 
> Recently I had unneccesary difficulty in connecting to inet via a 3Gdongle,
> because everybody uses the template: DoA, DoB...DoN, instead of the correct
> info: based on the physical reality.
> 1. only after it's confirmed that the PC has detected the USBdongle...
> 2. only after it's confirmed that the PC has switched the dongle out of CD-mode
> 3. only after it's confirmed that the USBmodem is being addressed...
> ...
> 
> A booter for OberonV5 for RISC for an emulator is like,
> a photo, of the mirror-image of Shroediger's cat.
> Or is it the mirror-image of the photo?

Is it useful or is it not useful? Only by opening the box and interacting with it can
you find out.

Warning: interacting with this linker may break the box. Be sure to have plenty
of extra boxes handy.

> The theory behind it, and not the code, plus pushA, pushB.. ; is interesting,
> and needs more explanation.
> 
> == Chris Glur.
> 
> 
> On 6/3/14, Charles Perkins <chuck at kuracali.com> wrote:
>> I have adapted Modules.Mod in the V5 RISC Oberon to make a separate Linker
>> module which may be used to create a new boot track binary file from within
>> the emulated RISC machine.
>> 
>> The separate module duplicates code, of course. It would be better to
>> enhance Modules.Mod with the ability to create the boot track. Perhaps I
>> will do that later if someone else doesn't do it first.
>> 
>> Source code and instructions can be found at:
>> https://github.com/charlesap/io/
>> 
>> I hope it is useful for someone besides myself!
>> 
>> Chuck
>> --
>> 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