[Oberon] Type compatibility in Oberon

[Guy T.]

I was used to do calculations as you mention. You have to take care of counter roll-over in the negative values and it doesn’t help to have reasonably clean codification. The other aspect is the interface with the underneath framework that supplies 64 bits values. At the end, I’ve decided to go with 64 bit LONGINT as I didn’t wanted to limit accessibility of the supplied framework interface to the end programmer. Sure it would have been possible to rely on an external C source code to take care of it, but if I can do everything in Oberon, I prefer. 

I’ve completed the codification for assignment, add, sub, mult, div, mod, abs. I now have to code relations and shifts. I will have enough capabilities for the usage I expect. It will remain some other functionalities that I will do later (like updating modules like Out, In, Text, other standard functions, etc.). For the div and mod operations, I rely on the ESP32 ROM that supply the functions to do it…

Cheers!
Guy

> On May 2, 2020, at 7:09 PM, Chris Burrows <chris at cfbsoftware.com> wrote:
> 
> 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
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon