Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #140766

Re: Compiler stress test

Show all headers | View raw

On 08/02/2019 00:20, Bart wrote:
> On 07/02/2019 22:24, David Brown wrote:
>> On 07/02/2019 22:26, jacobnavia wrote:
>>> Le 07/02/2019 à 14:08, David Brown a écrit :
>>>> In the Windows world, 32-bit Windows is still common.
>>>
>>>
>>> Windows Vista started in 2006 and offered the first 64 bit windows.
>>> Since then, 64 bit systems are the norm since there is since 2004 no
>>> intel CPU is 32 bit.
>>>
>>
>> The first 64-bit Windows was XP, not Vista.  (I had 64-bit XP on a
>> PC.) It was in 2005 (or 2002, for the Itanium).  Windows Vista was
>> universally condemned as a low point in Windows development, and was
>> never popular - much less the 64-bit version.  64-bit Windows only
>> really became mainstream with Windows 7 at the end of 2009.
>>
>> (For comparison, Linux supported 64-bit since 1995 on the Alpha, and
>> fully supported x86-64 in 2001 before hardware was even available.)
>>
>> So 64-bit Windows started having a non-negligible market share about
>> ten years ago.  Now, about half the Windows systems running are Win10
>> (almost all 64-bit), and about half are Win7 (with about half of these
>> being 32-bit, I would guess).  I failed to find good statistics, so if
>> you have a link you can certainly correct me - but my guess is
>> something like 20% of Windows systems are still 32-bit.
> 
> It's been some years now since since you've been able to easily buy
> 32-bit hardware for consumer PCs. (I think even RaspberryPi is 64-bit now.)

True.  But there are still lots of old systems around.

> 
> That's why I've turned my back on 32-bit machines, and my languages have
> switched to 64-bit, with 64-bit pointers, 64-bit default ints, 64-bit
> int constants and 64-bit everything (except chars and bytes that are
> still 8 bits).

There's nothing wrong with that.

If you have a build, test and distribution system that makes 32-bit
builds, then it takes time and effort to make a 64-bit version of that
system.  (How much effort will depend on many factors.)  If you change
from distributing one build to distributing two builds, you increase the
effort in making them, and in supporting them.  When you have one person
making the program, and one user - as you do - then the costs are
probably negligible.  When you have a company or community around the
product, and it consists of a lot of different parts, and there are many
customers and users with different systems - then it can be a very big deal.

So why move to 64-bit at all, if 32-bit will do the job fine?  If there
is no overwhelming reason, then it makes sense to stick to the existing
system that works perfectly well.  Maybe when you are bringing out a
major new version it will be time to make the switch.


> 
> And it's why it would be a surprise to find a recent version of a C
> compiler for such machines, to itself be built as a 32-bit program.

I would normally expect a modern compiler to be built as 64-bit, all
other things being equal.  But all other things usually are /not/ equal.

This particular example is, I believe, the "TDM" toolchain bundle for
Windows.  Let's look at a few points here:

1. TDM has been around since 2007, as far as I could see with a quick
check.  32-bit host would be the norm at the time.

2. TDM has made a specific point of having 32-bit programs where
possible (the exception seems to be for gdb for debugging 64-bit targets
- I guess it is more convenient for the debugger to be native).  This is
specifically explained under "quirks".

3. TDM's target audience appears to be normal C/C++ developers with a
wide range of systems, including much older ones as either host or
target.  Their users are not going to be the kind of development group
that actually needs large memories in the compiler - people working on
huge projects.

4. The project has not seen any changes in 3.5 years.


So /you/ might be surprised to hear that the compiler is built as
32-bit, but I am not - I find it reasonable enough.  (Equally I would
not be surprised to see it shipping both 32-bit and 64-bit packages, if
it were being actively maintained and developed.)


> 
> (C of course still uses 32-bit ints for the most part (for these PCs),
> with narrower types widened to 32 bits, but now there is also a
> discontinuity between 32 bits and 64 bits:
> 
>     int16 * int16 * int16 * int16
> 
> will be evaluated as int32 and could overflow int32, but would give the
> right answer as int64.)

The integer type system and promotion rules in C are well established.
You might not agree with them all (I don't), but they have absolutely
nothing to do with the sizes used by the compiler host or the compiler
binary.

> 
> 
>>
>> 2004 is when Intel shipped its first 64-bit x86 processor, and their
>> last 32-bit only mainstream processor was just after that (I think).
>> However, the most recently released Intel 32-bit only x86 processor is
>> the Quark SE C1000 from late 2015.  To be fair, the Quark processors
>> are aimed at embedded systems rather than desktops.
>>
>> Still, the Windows world is /slow/ to move to new technology.  All x86
>> processors were 32-bit long before Windows got any serious 32-bit support
> 
> That didn't matter as much for 32-bits: the 80386 was introduced in the
> late 80s I think, but on that device, it was possible to use 32-bit data
> instructions and registers even from a 16-bit program running under a
> 16-bit OS. (This is what I did in my compilers, long before everything
> else caught up.)

It certainly mattered enormously - dealing with any data structure over
64K was an absolute PITA.  And while there are few situations where
programs need access to more than 2GB of data, there are far more that
need more than 64K.

> 
> That wasn't possible with x64, where new 64-bit features can only be
> used in full 64-bit mode, and requires system support.
> 

Many of the features of amd64 are useable with 32-bit addressing (see
<https://en.wikipedia.org/wiki/X32_ABI>).  But it does need system
support - user mode code does not get to turn these things on and off
any more, unlike in the "good old days".

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-05 10:30 +0100
  Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:50 +1300
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:56 +1300
      strict aliasing rule on buffers slacked.misha@gmail.com - 2019-02-05 13:33 +0100
        Re: strict aliasing rule on buffers Richard Damon <Richard@Damon-Family.org> - 2019-02-05 08:13 -0500
        Re: strict aliasing rule on buffers Barry Schwarz <schwarzb@dqel.com> - 2019-02-05 06:00 -0800
        Re: strict aliasing rule on buffers David Brown <david.brown@hesbynett.no> - 2019-02-05 15:33 +0100
        Re: strict aliasing rule on buffers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-05 14:36 +0000
        Re: strict aliasing rule on buffers James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-05 07:27 -0800
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-07 08:28 +1300
      Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 19:48 +0000
      Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-06 22:11 +0100
        Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 00:34 +0100
          Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 07:13 +0100
            Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 08:32 +0100
              Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 12:06 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 14:08 +0100
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 13:49 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 17:01 +0100
                Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 22:26 +0100
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 23:24 +0100
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 23:20 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 10:42 +0100
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:37 +1300
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 12:30 +0100
                Re: Compiler stress test Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 08:18 -0800
                Re: Compiler stress test scott@slp53.sl.home (Scott Lurndal) - 2019-02-08 16:04 +0000
                Re: Compiler stress test Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-11 20:34 +0000
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:30 +1300
  Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 12:20 +0000
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:59 +1300
      Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 21:57 +0000
        Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 00:29 +0100
          Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 23:58 +0000
            Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:10 +1300
              Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 01:16 +0000
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:21 +1300
                Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-06 01:28 -0500
                Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-08 03:51 -0500
            Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 08:13 +0100
      Re: Compiler stress test BGB <cr88192@hotmail.com> - 2019-02-06 13:13 -0600

csiph-web