[Oberon] Type compatibility in Oberon

[Chris Burrows]

The processor designers must be optimistic that their processor is going to be in use for some time to come. Using 64-bits to count time in microseconds allows for an event that lasts more than 35,000 years to be timed ;-)

Having to implement Oberon-90, Oberon-2 or Modula-2 (or some new language of your own design) to properly implement support for multiple-size INTEGERs sounds like overkill to me if this is the only occasion 64-bit INTEGERs are required. An alternative solution would be to handle this within your 'Timer' library module. 

Typically if you are using a microsecond timer you are interested in events that last a few seconds or maybe, a few minutes?. Longer events rarely need such a fine resolution. If you just use the lowest 31 bits of the clock you can keep track of time in microseconds up to a limit of just over 4 mins. Internally you can keep track of the number of seconds and microseconds that have passed and reset the clock (assuming you can do that) every time four minutes is exceeded. If you can't reset the clock then you might need to monitor changes in the LSB of the upper 32-bits of the clock instead.

An even simpler solution for you but a bit more work for the end-user would be to limit the time that can be measured after a timer reset to 4 minutes. It would then be the application programmer's responsibility to implement a solution if he wanted to time events longer than that in microseconds.

Regards,
Chris Burrows
CFB Software
https://www.astrobe.com


> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Guy T.
> Sent: Saturday, 2 May 2020 11:10 PM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Type compatibility in Oberon
> 
> I m currently implementing 64 bits LONGINT on a 32 bits processor. Main
> reason is related to the internal clock micro-seconds information returned
> by the hardware using 64 bits. I m using  L  suffix to supply LONGINT
> hexadecimal constant values. When a decimal constant is defined, if it is
> too big to fit in an INTEGER, it is then considered to be a LONGINT. A
> decimal LONGINT constant cannot be negative unless it is part of an
> expression in the declaration (from the parsing process in the compiler
> expression() function).
> 
> LONGINT implementation on a 32bit CPU is a good challenge but doable
> 
> Guy
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon