64 bit version of lcc-win

[jacob navia]

Preview:

lcc-win 64 bits has had a long development period, and is not
complete yet. But a preview of the software will be available
with the professional version of lcc-win.

It features:
o 128 bit integer support. Contrary to the 32 bit version,
this will be native support, i.e. in most cases there
will be no overhead, except for 128 bit division, where
a function call is generated.

o New qfloat support, featuring increased precision (132
digits instead of 105 for the 32 bit version) and a
slightly improved speed, even if precision went up.

Obviously the 64 bit version supports address spaces
much bigger than the 32 bit version.

The debugger has been changed to support the 64 bit version,
and a 64 bit version of the gc package is available. This part
was ported to 64 bits mainly by Friedrich. It was a really
difficult part of the port.

The package will be available beginning next week.

 

[Keith Thompson]

Preview:
lcc-win 64 bits has had a long development period, and is not
complete yet. But a preview of the software will be available
with the professional version of lcc-win.

It features:
o 128 bit integer support. Contrary to the 32 bit version,
this will be native support, i.e. in most cases there
will be no overhead, except for 128 bit division, where
a function call is generated.

Is long long still 64 bits? What are the names of your 128-bit
integer types? Are they "extended integer types" as described in C99
6.2.5? Do intmax_t and uintmax_t refer to your 128-bit types?

Since you've been a vocal advocate of the C99 standard, I would hope
that you've taken advantage of the features it provides rather than
just inventing your own.

o New qfloat support, featuring increased precision (132
digits instead of 105 for the 32 bit version) and a
slightly improved speed, even if precision went up.

Is this extension provided in a manner that doesn't affect strictly
conforming programs? If not, is it enabled only in a non-conforming
mode?

[...]

I'm hoping that you're willing to discuss actual C language issues,
and not just posting a commercial advertisement (which would be
entirely inappropriate in comp.lang.c).