Question: Support values larger than calc v2 limits, require c99 <stdint.h> support, and move to calc version 3?

[lcn2]

TL;DR question

Should calc change to version 3, support values those "digit" lengths are limited by 64-bit signed value (this change the ZVALUE memory layout), drop support for 16-bit processors and 32-bit processors that do not have at least a c99 compiler with <stdint.h> include file?

Even so, please read the rest of this discussion ...

Background - calc v2 limits

Historically calc version 2 has limited integers to 268435455 "digits" where a "digit" is 32-bit (or 16-bits in some cases of very small processors). For 32-bit "digits" integers are limited to a maximum of about 8589934588 bytes. Non-integer real numbers are implemented as fractions consisting of 2 integers, "a/b", where an and b are both subjected to the same limits. Complex values consist of 4 integers, "a/b + sqrt(-1)*c/d", where a, b, c, and d are also subjected to the same limits.

There are other limits, such as the exponent must fit into a 32-bit (or fir small processors 16-bit) digit (called a HALF inside calc).

For 32-bit "digits" or HALFs the largest exponent was 4294967295. So, for 32-bit HALF, calc can attempt to compute 2147483648^2147483647 if the machine had enough memory.

BTW: Converting 2147483648^2147483647 will take a LONG TIME, however you can push close to the maximum value edge with:

; a = 2147483648^2147483647
; memsize(a)
	8321499220

is fast, assuming a system had enough memory, and you don't try to allocate too many such values. :-)

This also assumes your processor can support addresses larger than 32-bits in size, otherwise you are even more limited. A true 32-bit processor would run out of memory with values probably about 1G byte in size (due to memory needed for stack, instructions, etc.)

Fortunately, most hardware running today can support addresses larger than 32-bits in size.

Backward in calc compatibility is important

Calc has been around since 1984. Part of its stay power is that calc code written long ago still works. Calc runs in a very wide variety of processors, custom hardware, and devices: both big and small. Backward compatibility has been an import part of calc history. The calc tool has gone to significant efforts to maintain backward compatibly, especially for those hardware implementations that use custom functions. For example, the layout of the above integers, the ZVALUE type, has been the same for nearly 4 decades.

The ZVALUE contains a length element that is the number of HALFs in a ZVALUE. For calc v2, this length is currently a 32-bit signed value. Lengths are signed values and not unsigned values for various internal and algorithmic reasons. Even if we changed to a 32-bit unsigned length, that effort would only "kick the can" down the road only twice as far.

Supporting values larger than calc v2 limit

To support even larger integers, the ZVALUE would need to change its memory layout. In particular, the ZVALUE HALF length element became a 64-bit signed value.

The largest exponent allowed would need to be raised from a 32-bit exponent to a 64-bit exponent.

A change to using a 64-bit signed ZVALUE length element would change the fundamental internal memory layout of calc.

The philosophy of version numbers outlined in:

; help release

states that when the internal memory layout changes, the top-level version number MUST CHANGE. Thus, to do this calc would need to advance to version 3.

CALC2_COMPAT and calc version 3

Since commit 3c18e6e, calc supports the define of CALC2_COMPAT. Any calc version 2 today defines CALC2_COMPAT by default.

In the proposed calc version 3, CALC2_COMPAT would be ** UNDEFINED by default**.

In the proposed calc version 3, if one were to force CALC2_COMPAT to be defined, then ZVALUE HALFlength to be limited to is current 32-bit signed value. Such binaries would use a memory layout that was **compatible with current calc v2 memory layouts**. Acalcorlibcalcorlibcustcalcwith version that was compiled with CALC2_COMPAT defined would be **INCOMPATIBLE** with default calc v3 code whereCALC2_COMPATwas undefined. Nevertheless, if one wanted to have a calc version 3 memory layout that was compatible with the current calc v2 memory layouts, one could compile with CALC2_COMPAT defined. One would just not be able to link with calc code whereCALC2_COMPAT` was undefined in that case.

Dropping support for 16-bit CPUs without c99 fixed-width integer types

Calc v2 supports a 16-bit HALF as well as a 32-bit HALF. Modern processors can use integer machine values such that in calc version 2, they default to a 32-bit HALF size.

It will be awkward to support 16-bit HALF code in calc version 3. Nevertheless after 39 years, perhaps it is time for calc in the proposed version 3 to drop support of 16-bit CPUs? :-)

Such 16-bit CPUs can always download the latest calc version 2 source and use that code. Or one could use a c99 or later compiler to compile fixed-width integer types for such a 16-bit CPU. Such a C compiler implementation, under the covers, would compile the appropriate instructions to simulate computing with a 32-bit HALF size.

Limiting support for 32-bit CPUs without c99 fixed-width integer types

In several cases, 32-bit processors were limited to 16-bit HALFs as well. Such 32-bit processors used a long as a FULL when it needed to multiple two 16-bit HALFs and get a 32-bit result.

Calc version 3 will be able to support 32-bit CPUs that either support a 64-bit integer data type in C. In several 32-bit CPUs, a long is sometimes 64-bits, so such systems would be OK under calc version 3. However, if a 32-bit CPU lacked C support for 64-bit integers, it would not work under calc version 3.

Again, such 32-bit CPUs could use a c99 or later compiler to compile fixed-width integer types for such a 32-bit CPU. Such a C compiler implementation, under the covers, would compile the appropriate instructions to simulate computing with a 64-bit FULL size.

c99 (or later) compilers and fixed-width integer types

Starting with calc version 2.15, calc will require support of <stdint.h> and the fixed-width integer types. Calc will replace data types such as USB32, SB32, USB64 and SB64 with standard C types such as int32_t, uint32_t, int64_t and uint64_t.

Calc will keep the HALF and FULL data types. It would simply typedef then to the appropriate fixed-width integer type.

The c99 standard requires that implementations support such types. A 16-bit CPU, or a 32-bit CPU that supports a c99 or later C compiler would still work. Such a C compiler implementation, under the covers, would compile the appropriate instructions to simulate computing with 32-bit HALFs and 64-bit FULL sizes.

Calc would require a c99 or later C compiler and implementation with full <stdint.h> support.

128-bit future

With fixed-width integer types AND some newer C compilers, the possibility of calc using 128-bit data types is there. In such a case calc would support a 64-bit HALFs and 128-bit FULL values.

This would allow for the implementation of issue #48 as well.

Calc would test for the __int128 and unsigned __int128 data types and if found, allow those types to be used. If the compiler implements them, then calc would typedef HALF to a 64-bit data type and FULL to a 128-bit data type.

The default, without __int128 and unsigned __int128 data type support, would be BASEB == 32. However with __int128 and unsigned __int128 data type support, BASEB == 64 would be used.

This would be similar to how BASEB of either 16 or 32 works now: we would simply shift the level up by a factor of 2.

And if/when int128_t and uint128_t became standard, calc would switch to supporting that via typedefs.

Doing all the above would make implementing 128-bit operations and implementing BASEB == 64 practical for those C compiles with __int128 and unsigned __int128 data type support.

[lcn2]

Please feel free to add comments, suggestions, complains and corrections as new comments below.

Don't forget to click the ((Vote)) button after selecting your choice above.

[ilyakurdyukov]

The proposal to include int128_t type in C:

https://open-std.org/jtc1/sc22/wg14/www/docs/n2888.htm

I don't know if it was accepted or not.

[lcn2]

Thanks @ilyakurdyukov, that's good to know.

Calc would use some type name such as calc_int128_t and calc_uint128_t and then typedef them to whatever is currently supported.

[lcn2]

We have hard from calc users who have hardware accelerators that use calc' as custom functions and higher level builtin functions. So far all are in favor of the proposed version 3 change. Some have been asking for near-terabyte ZVALUE capabilities for a few years. They are not GitHub users but wanted us to indicate their support anyway.

We heard from a vintage computer hardware fan who runs a version of calc in both an 8086 and a z80. Via email they said they have a c99 compiler that can pass the chk_c.c test: that's impressive considering how much machine code is needed to implement 64-bit multiplication using 8-bit and 16-bit register ops! That said that running calc's regression test suite takes awhile, but it does pass eventually.

[ilyakurdyukov]

I didn't understand why you can't support BASEB which could be 16/32/64 in one version. Why is it 16/32 or 32/64.

(or four small processors 16-bit)

Typo: four instead of for.

that's impressive considering how much machine code is needed to implement 64-bit multiplication using 8-bit and 16-bit register ops!

I think that 16-bit machines should use the old version.

[lcn2]

I didn't understand why you can't support BASEB which could be 16/32/64 in one version. Why is it 16/32 or 32/64.

Fair point. We could support BASEB of 16, however if we are going to require a c99 or later compiler, then the machine WILL have 32-bit and 64-bit integers and so there is no point in supporting a BASEB of 16.

Even the 8086 processor implementation that has a c99 compiler uses a BASEB of 32.

So it comes down to code complexity. By requiring at least a c99 compiler we know that there are 32-bit and 64-bit data types and thus there is no need for a BASEB of 16. OK, maybe there is some speed issue of some 8-bit or 16-bit CPU where BASEB of 16 might be faster than an BASEB of 32 or more. However that is a fairly narrow use case for a legacy CPU at the expense of code complexity.

We will, however plan to support a BASEB value of 32, 64 and even 128 where there is support for a 256-bit data type. So we plan to support at least a 3-way BASEB codebase. We could expand that to a 4-way BASEB codebase, but as stated above, with c99 or later there isn't a need for the BASEB if 16 case.

Typo: four instead of for.

Fixed, thanks!

I think that 16-bit machines should use the old version.

Machines without a c99 or later C compiler will have to use the old 2.x version of the code anyway.

[pmetzger]

Just on the C99 issue: it has now been 24 years since C99, and even many historic systems (like Vaxes) have versions of gcc etc. that support C99. I think it's totally fine to say "if you have an old system, find a C99 compiler." C99 has a lot of nice features and it's been a very long time since I've personally made any attempt to be compatible with older versions of C than that.

On the 16 bit thing: does anyone actually have a functioning 16 bit computer that can run calc? I'd be shocked. If they do, they can always run an older version, and I doubt they're using such a machine as their daily driver.

[lcn2]

Just on the C99 issue: it has now been 24 years since C99, and even many historic systems (like Vaxes) have versions of gcc etc. that support C99. I think it's totally fine to say "if you have an old system, find a C99 compiler." C99 has a lot of nice features and it's been a very long time since I've personally made any attempt to be compatible with older versions of C than that.

Good points.

On the 16 bit thing: does anyone actually have a functioning 16 bit computer that can run calc? I'd be shocked. If they do, they can always run an older version, and I doubt they're using such a machine as their daily driver.

The 8086 system we are aware of gets pulled out for show at a vintage computer show. So no, there isn't much call for it. :-)

[lcn2]

We received via messages, 4 more YES votes.