Re: is Vax addressing sane today

On Sun, 29 Sep 2024 16:19:38 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Tim Rentsch wrote:

EricP <ThatWouldBeTelling@thevillage.com> writes:
 

Lawrence D'Oliveiro wrote:
 

On Thu, 26 Sep 2024 13:13:02 -0400, EricP wrote:
 

I've always paid for mine.  My first C compiler came with the
WinNT 3.5 beta in 1992 for $99 and came with the development kit,
editor, source code debugger, tools, documentation.
A few hundred bucks is not going to hurt my business. 

>
Given that GCC offers more features and generates better code than
MSVC, the money may not matter to your business, but the quality
of the product will. 

>
GCC is a compiler collection not a integrated development kit for
Windows. I have no knowledge of what state GCC was in in 1992 but
it likely did not support the MS enhancements for Win32
programming: structured exception handling, various ABI's, inline
assembler, defined behavior for some of C's undefined behavior,
later first-class-type support for 64-bit signed and unsigned
integers, and most important:  integration with the GUI source
code debugger.
>
Plus come with necessary API headers, various link libraries and
DLL's, supporting applications, documentation.
You know... what a product looks like. 

 
I am currently in the position of needing to take some code
written for Linux/Unix and get it running in MS Windows.
 
My attempts to use MSVC have been frustrating, because of some
limitations of that environment.  The two most prominent are
these:  long double is only 64 bits, and there are no integer
types of 128 bits that I could find.
 
Are there any MSVC folks here who can help with these problems?
I am not an MSVC expert by any means and easily could have missed
something.
 
I should mention that the code is written in C, not C++, and that
is not something I am at liberty to change.
 

I seem to remember finding something like __int128_t and __uint128_t
inside MSVC?
>

Very unlikely.
Most likely your are thinking about C++ rather than C.
Newer versions of Microsoft's STL appear to feature intentionally
undocumented 128-bit integer classes std::_Signed128 and
std:_Unsigned128.

And that by casting uint64_t parameters to the u128 variant, the
compiler would generate the obvious MUL RDI and save RDX:RAX as the
128-bit result:
 
uint128_t mulw(uint64_t a, uint64_t b)
{
   return (uint128_t) a * (uint128_t) b;
}
 
I.e. no subroutine call/zero overhead.
 

That is not MSVC.
For this specific case, MSVC has a [better] solution in form of
intrinsic ___umul128. But it wouldn't help Tim, because he is not
allowed to modify the sources.

OTOH, getting optimal wide integer accumulators is a bit harder,
needing compiler intrinsics to access the widening add with carry
opcodes. (ADDX)
 
Terje
 

That's correct about intrinsics, but incorrect about ADCX/ADOX.
The later can be moderately helpful in special situuations, esp.
128b * 128b => 256b multiplication, but it is never necessary
and for addition/sbtraction is not needed at all.