[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