Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Sun, 29 Sep 2024 18:00:26 +0300
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <20240929180026.00004160@yahoo.com>
References: <vbd6b9$g147$1@dont-email.me>
	<2024Sep10.094353@mips.complang.tuwien.ac.at>
	<vckf9d$178f2$1@dont-email.me>
	<O2DHO.184073$kxD8.113118@fx11.iad>
	<vcso7k$2s2da$1@dont-email.me>
	<efXIO.169388$1m96.45507@fx15.iad>
	<8f031f2b5082d97582b1231a060f2b9f@www.novabbs.org>
	<8DgJO.171468$1m96.17060@fx15.iad>
	<vd7peh$12kpl$2@dont-email.me>
	<KWUJO.41016$vtH3.33971@fx07.iad>
	<86msjr2bec.fsf@linuxsc.com>
	<vdbnlq$1pabr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 29 Sep 2024 16:59:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1c937c2e7b01fb16cab4b41feb8475c";
	logging-data="1858602"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+HJquwqjUUzNIfMTYZWNxH9SN9kqQs/Nk="
Cancel-Lock: sha1:VT94yatYF/amEfjMQXnzFii06fs=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4680

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.