[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 64-bit extensions
Mike Griebling (grieblm@trt.allied.com) schrieb:
>Just thought I would start a discussion on 64-bit extensions
>to Oberon-2. As a starting point, let's assume the Component
>Pascal definitions:
Before doing your own design I propose to look closly to the design Gnter
and I made at ModulWare:
http://ourworld.compuserve.com/homepages/modulaware/
I'll port Alpha Oberon to 64 bit soon as my diploma thesis, so practical
experience about this design will be availabe in some time.
Here my specific comments:
> BYTE = signed 8-bit number
> SHORTINT = signed 16-bit number
> INTEGER = signed 32-bit number
> LONGINT = signed 64-bit number
Such a definition will definitly disable ease porting of existing
application, first of all the Oberon System. Reason: BYTE has to be same sice
as SHORTINT.
2nd problem: BYTE is not an integer type in Oberon but this is at least
implied in the defintion above.
>SYSTEM (at least for Oberon-2). Another nice aspect is that
>any program which works now should continue to work with these
>new definitions -- with some memory penalty.
I'm afraid it will not. I considered this type defs, too, but found som
reasons against it (sse the paper).
>What are people's thought's about extending the CHAR type as
>well? Personally, this is not a big deal for me, but our
I would prever a seperate uni-char type.
>1) Our data types would be much closer to the Java virtual
> machine; perhaps making an Oberon-2 to Java byte code
> back end simpler.
This is not a question of the data types names.
>3) OOC would be compatible (sort of) with the Component
> Pascal compiler.
Not an argument, if CP's design is dull.
>2) Loads/arithmetic operations might be slower -- at least
> on a 32-bit processor emulating a 64-bit processor. Of
Some processors will not be able to handle this (e.g. 68K).
+++hartmut