[Oberon] Proof of Concept, ARM Linux Oberon
lab.eas at gmail.com
Sun May 4 18:48:33 CEST 2014
]> Perhaps if we understood how/why the following
]> script <links V4 from it's resident-dir to where it currently
]> 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
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:
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>
]> 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,
#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.
== Chris Glur.
More information about the Oberon