[Oberon] Re (2): V4, 64 bit version;

Charles Perkins chuck at kuracali.com
Sat Jan 16 01:13:42 CET 2021


I intend to leave .rsc alone. I've added a switch to ORP for cross
compilation to other architectures. Intel binaries end up with the .i64
extension, Arm gets .a64 (or .a32 for 32-bit arm) and risc-v gets .v64 (or
.v32 for 32-bit risc-v.) The file extension choices were arbitrary.

With this convention a single file system may potentially be booted on any
of the above architectures.

For development I already have a QEMU setup that loads and begins executing
a Oberon-produced code for x86_64, aarch64, arm32, rv64, and rv32. I also
have a QEMU RISC5 emulation that boots all the way to graphics and command
execution.

The Oberon-produced code for the other architectures is currently nothing
more than a jump over global variables and then an infinite loop. Next up:
serial output of a test string!

On Fri, Jan 15, 2021 at 3:57 PM Joerg <joerg.straube at iaeth.ch> wrote:

> I guess you will stick to the RISC5 instruction set. You have to decide,
> whether you want to store the rsc files in 32bit (as today) or will store
> them in 64 bits as well (although only 32 bits are used). Your decision has
> an influence on the bootloader, compiler and the loader.
>
> br
>
> Jörg
>
>
>
> *Von: *Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Charles
> Perkins <chuck at kuracali.com>
> *Antworten an: *ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> *Datum: *Samstag, 16. Januar 2021 um 00:32
> *An: *ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> *Betreff: *Re: [Oberon] Re (2): V4, 64 bit version;
>
>
>
> In my case the interest is being able to use the full capabilities of a
> 64-bit platform, including addressing more than 4 gigabytes of RAM.
>
>
>
>
>
>
>
> On Fri, Jan 15, 2021 at 2:37 PM <peter at easthope.ca> wrote:
>
> From:   Charles Perkins <chuck at kuracali.com>
> Date:   Fri, 15 Jan 2021 13:17:03 -0800
> > On review of the source, I see that LONGREAL is currently aliased to REAL
> > in ORB, suggesting that REAL may stay 32-bit and LONGREAL would be
> 64-bit.
> > Would the same be done for SET, introducing LONGSET perhaps?
>
> From the new Project Oberon book I had the impression that the gain of
> one type rather than two outweighed the loss of storing some numbers
> in capacities larger than necessary.
>
> If so, wouldn't any machine have only REAL, according to hardware
> capability, whether 32 bits or 64 bits or 128 bits?
>
> What are the requirements motivating interest in 64 bits?  Numerical
> modeling?
>
> Thanks,                     ... P. L.
>
> --
> Tel: +1 604 670 0140            Bcc: peter at easthope. ca
>
> --
> 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
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20210115/a6d9fed9/attachment.html>


More information about the Oberon mailing list