[Oberon] Oberon on the Raspberry Pi

[eas lab]

SO ALO is quiet USABLE on rPi.
Here's an UNSANATIZED log of a REAL task performed by ALO.

Unfortunately I must paste it into a little window of this crappy httpGmail.
===
=> I'm posting this effort to rPi group also:--

Did I post my work on HOW2 set rPi's  /boot/C*ext for a suitable Frame
& font size?  My email is screwed since I lost permission to use ETHO.

Has ALO got Open/Store procedures for FAT & unix yet, or should I just
copy some code from exiting ETHO procedures?

I didn't continue testing V5 because it couldn't access the outside-world -YET.
We need to be able to roam the complete directory, and launch <ETHO>
from anywhere, like the factory-manager who knows and can control
anything.  LEO is great for that.

If you've got several ALOs running, eventually it's confusing : "where is
this one based?"
Here's a good trick, for someone to explain to the M$-boys:
   in the launched-dir, under linux: pwd >> pwd
   then when in ALO, klux pwd, will show the file:pwd with eg:
/usr/local/ALO140418

This is not ideal, since it contaminates the launced-dir with the file:pwd.

Also we need to be able to access any file in the dir-tree from whereever
that ALO was launched. LEO is great for that too.
Perhaps Linux:V4's start script shows how to. IIRC it uses links.
I never suceeded in understanding it - *YET*.
Right now I'm writing in ALO. If I was in LEO, I could just search/find/copy
& paste the V4-script, right here, ALL ON THE SAME  SCREEN.
I'll paste it after I move this ALO originated text to the PC for mailing.
[Now back in PC:linux:LEO, this post is already too long!]

That's how tasks are interlinked & complex.
That' why we need several files viewable TOGETHER.
Which the ETHO family gives us.

Let's pasteNklux:-
System.ShowCommands  ARMDecoder.Mod == ARMDecoder.Decode
 ARMDecoder.Decode Hello.Mod == Object file dump

Name: Hello     Tag: 245 48     Key:  00000000


Code size: 124  Var size: 0     Strconst size: 12       Entries: 1      Pointer
s: 0    TDescs: 0       Imports: 2

Imports:
         4905336C Out
         49053365 SoftFloat
...etc. bl..bla
Code:

Procedure World:
 00000000        E92D5000       STMDB           SP!, {FP LR }
 00000004        E1A0C00D       MOV             FP,SP
 00000008        E25DD008       SUB  S          SP,SP,8H
 0000000C        E59FB04C       LDR             RB,[PC,+4CH]            ( = 96
( 00000060H)  )
 00000010        E50CB004       STR             RB,[FP,-4H]
...etc. bl..bla

?! Surely this is not actual disassembly of ARM machine code?
It's the carry-over from X86 ?

-> Linux: dd if=Hello.Obj  | hexdump -C  {LEO can do this, without switching to
linux}
00000060  b0 9f e5 04 b0 0c e5 48  b0 9f e5 08 b0 0c e5 0c  |.......H........|
00000070  b0 a0 e3 04 b0 2d e5 3c  b0 9f e5 04 b0 2d e5 01  |.....-.<.....-..|
00000080  01 00 00 04 b0 1c e5 08  a0 1c e5 04 b0 2d e5 04  |.............-..|
00000090  a0 2d e5 0b 02 16 00 04  00 2d e5 0c b0 a0 e3 b4  |.-.......-......|
... has similarity " e5 0z b0
 00000010        E50CB004       STR             RB,[FP,-4H]
 00000014        E59FB048       LDR             RB,[PC,+48H]  ( = 100 ( 0000006
4H)  )
 00000018        E50CB008       STR             RB,[FP,-8H]

This is where ETHO shines: when you've got 8 files open-on-the-screen,
and you must compare/associate parts of different files.
So I use COLOURS, which YOU can't see once I mail this 'Log'.
==> Well only the " E50CB0" seems to be common. But the 'endian' problem?

Since Hello.Obj is only 259 bytes, I'll try to modify it to contain easily recog
nisable byte/s
in the objectCode. %55 [=85] is recognisable, so:--

MODULE Hello55;
IMPORT Out;

PROCEDURE Test*;
BEGIN
        Out.String("Test x55=85"); Out.Int(85+85-85, 4); Out.Ln;
END Test;

END Hello55.   ARMCompiler.Compile  * == compiling Hello55 new symbol file 80

World55.Test   == Test x55=85  85 <- looks OK
? Let's see if the byteString contains: x55
Of course with 'normal' ETHO, you've got Hex.Tool, but we can just switch to *ni
x
to examine a file's bytes-contents.
-> dd if=Hello55.Obj | hexdump -C | grep 55 ==
00000020  93 12 33 49 48 65 6c 6c  6f 35 35 00 85 6c 33 05  |..3IHello55..l3.|
00000060  00 00 55 b0 a0 e3 04 b0  2d e5 04 b0 a0 e3 04 b0  |..U.....-.......|
00000090  a0 e1 00 90 bd e8 87 54  65 73 74 20 78 35 35 3d  |.......Test x55=|

Meanwhile our ARM code officianado has confirmed that the following is ARM
 ARMDecoder.Decode Hello55.Mod == ....
 00000018        EB000101       BL              424H
 0000001C        E3A0B055       MOV             RB,55H <- WHAT's this?!
 00000020        E52DB004       STR             RB,[SP,-4H]!
 00000024        E3A0B004       MOV             RB,4H

OK, by marking the text with colour/s I now see the correspondence:
55 b0 a0 e3  <-> E3A0B055
04 b0  2d e5  <-> E52DB004
Can YOUR system KokiColoredPen mark the screen text, like ETHO?

So my problem was the 'endian-ism' of the 4-byte-words?    Or?

==Chris Glur.

PS. I've also researched setting rPi Frame & font size via /boot/con*ext
 for anybody who's got problems.