[Oberon] Proof of Concept, ARM Linux Oberon

[eas lab]

]>    Perhaps if we understood how/why the following
]> script <links V4 from it's resident-dir to where it currently
accesses files>,
]> we could do similar for ALO ?
]
]The systems I ported don't use Linux libraries. So these technics are
]not possible. However, Next version will include OFSTools so that Linux
]directories can be mounted the "native" way. Also "/" will be allowed in
]filenames which allows something likes "../foo/bar" as long as the
]filename length is within Oberon limits.

OK, it's easier for me to test these ideas on LNO. ALO needs a Load/Save
unix/FAT format.
The following is OK, for launching LNO/ALO to work on any node of the dir-tree:
 a script that writes <mount this dir as linux at $PWD> to a fixed location
  of LNO/ALO 's resident Dir.

This only needs:
1. ALO2 <-- to write the LNO/ALO above-command and launch a new LNO/ALO
2. in the newly launched LNO/ALO one klux to open the written Text of above-cmd
  + 1 klux to execute it.

For me ETHO is less about the minimalist syntax & strong typing, than
the minimal manual steps, and not needing the remember names.
The above satisfies my needs.

When N-O was extended to have multiple-partitions for the file space I decried
the extra level of complexity. But it worked out very nicely for me. I had ca.
12 'topics', each with a line in my.Tool like:
  Configuration.DoText MountTelCom
klux 1st token = mounts the partition
klux 2nd token opens the tool, which shows the history of the partition-bakup
 and templates eg. to <find multiple strings in all files of the partition>
  ..etc.


]> PS. I started using ALO's Decoder.Mod on some ARM binary-code,
]> but stopped when I saw that ARM seems very convoluted/irregular.
]
]I think ARM is neither convolutet nor irregular. It was the system where
]I once understood assembler (after failing with 68k-Assembler).

Well I expected the machine code to differ by only one, predictable byte,
 between:
 #55 -> R2      and  #AA -> R2
 and by two predicable bytes for
 #1 -> R1      and   #2 -> R2
but that seems not to be the case.
I wanted to make a kind of P-code interpreter for debugging.

The fact that rPi doesn't boot via the CPU, but has a further layer of
complexity of the 'GPU' is also disencouraging.

 Thanks,

== Chris Glur.