[Oberon] PO.Computer documentation (was: Compiler Modules Empty?)

[eas lab]

Chris Burrows wrote:-
]....It sounds as
]though you have an obsolete version of PO.System.pdf and you don't have
]PO.Computer.pdf. Try downloading the documentation again.

]Chapters 16 'Implementation of the RISC processor', and Chapter 17 'The
]processor's environment' are included in the separate file: PO.Computer.pdf.

You have chosen to ignore my [now snipped] pageNo.-description [which is
available from the pdf] and change it to Section-description, which also matches
my pdfS.

>
]> PS. Nobody ever mentioned the ETHO x86 <dis-assembler>, whose output is
]quite
]> fascinating.

]The equivalent is available for ProjectOberon RISC5:
]
]  ORTool.DecObj*   (*decode object file*)

Yes, I'll study that, which may be a template for bigger
architectures; meanwhile
since you're expert in ARM-code can you confirm IF the following bytes match the
source:----
OMG !! I can't paste from the rPi to the PC; so I'll go via paper.

 a:=3.2; b:=34.0;
Out.String("Hello World"); Out.Real(a*b, 12);Out.Ln;
====
e8 bd 90 00  SP! {FP PC}
...
eb 00 01 04   BL 468H
eb 00 01 08   BL 47cH

?BL sounds like branchOnLess; but HelloWorld has no decisions?

== Chris Glur.




On 4/23/14, Chris Burrows <chris at cfbsoftware.com> wrote:
>> -----Original Message-----
>> From: eas lab [mailto:lab.eas at gmail.com]
>> Sent: Wednesday, 23 April 2014 10:56 PM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] Compiler Modules Empty?
>>
>> => PO.System.pdf <- Ends at 9.5
>> => PO.Aplications.pdf ends at pg 86.
>
> There should be no appendices listed in the table of contents. It sounds as
> though you have an obsolete version of PO.System.pdf and you don't have
> PO.Computer.pdf. Try downloading the documentation again.
>
> Chapters 16 'Implementation of the RISC processor', and Chapter 17 'The
> processor's environment' are included in the separate file:
> PO.Computer.pdf.
>
>>
>> PS. Nobody ever mentioned the ETHO x86 <dis-assembler>, whose output is
> quite
>> fascinating.
>
> The equivalent is available for ProjectOberon RISC5:
>
>   ORTool.DecObj*   (*decode object file*)
>
>>
>> IMO writing machineCode in Oberon is as wrong as writing music scores in
>> natural-language.
>
> Huh? I wasn't aware anybody was writing machine code in Oberon. The
> compiler
> generates machine code not the programmer.
>
>
> Regards,
>
> Chris Burrows
> CFB Software
> http://www.cfbsoftware.com
>
>
>
>
>
>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>