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

Groups > comp.lang.c > #112176 > unrolled thread

Type system protocols rest atop fundamental data

Back to article view | Back to comp.lang.c

Contents

  Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:14 -0700
    Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:18 -0700
      Re: Type system protocols rest atop fundamental data mark.bluemel@gmail.com - 2017-06-14 08:00 -0700
        Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 08:06 -0700
      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 20:39 +0100
        Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:51 +0100
          Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 22:25 +0100
            Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 14:37 -0700
              Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 00:32 +0100
                Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 17:02 -0700
                  Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 01:34 +0100
                    Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-14 20:28 -0500
                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
                    Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 20:02 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 10:29 +0200
                      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 10:54 +0100
                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 13:15 +0200
                          Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 13:51 +0100
                            Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 16:13 +0200
                            Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:01 +0100
                              Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:27 -0700
                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:35 -0700
                    Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-17 16:10 -0700
                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 19:23 -0700
                Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:13 +1200
                  Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 18:44 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:42 +0200
                      Re: Type system protocols rest atop fundamental data Gareth Owen <gwowen@gmail.com> - 2017-06-16 20:20 +0100
                      Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 00:32 -0500
                        Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 11:06 +0000
                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 15:26 +0200
                      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-18 14:58 +0100
            Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 01:42 +0100
              Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 11:52 +0100
                Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:07 +0100
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
                Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:52 -0700
                  Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 10:36 -0700
                    Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 17:58 +0000
                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 11:48 -0700
                        Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 19:01 +0000
                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 12:29 -0700
                            Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:47 +1200
                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 19:33 -0700
                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 13:02 -0700
                            Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 13:09 -0700
                            Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 22:25 +0200
                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 14:23 -0700
                                Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 23:53 +0200
                                  Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 15:39 -0700
                                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:50 +0200
                                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 08:40 -0700
                                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:49 +0200
                                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 10:33 -0700
                                            Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 17:50 +0000
                                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 12:12 -0700
                                                Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 19:27 +0000
                                            Re: Type system protocols rest atop fundamental data Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 15:18 +0000
                                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 09:30 -0700
                                      Re: Type system protocols rest atop fundamental data David Kleinecke <dkleinecke@gmail.com> - 2017-06-16 12:05 -0700
                                        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 12:30 -0700
                                          Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:54 +0200
                                            Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 13:25 -0700
                                              Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 09:27 +0200
                                                Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 08:53 -0700
                                                  Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 22:12 +0200
                                                    Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:14 -0700
                                                      Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:16 -0700
                                                    Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 14:04 -0700
                                                      Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-21 15:33 +0200
                                              Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-20 13:25 +0000
                                        Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 19:42 +0000
                                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:58 +0200
                                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:18 +0000
                                  Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-15 23:40 -0500
                                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:51 +0200
                                      Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:55 +0000
        Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:23 -0700
          Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:48 +1200
            Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 19:03 -0700
              Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 15:12 +1200
                Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 20:20 -0700
                Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 07:03 +0100
                  Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 20:01 +1200
                    Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 19:21 +0100
                      Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-16 12:07 -0700
                      Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-17 16:18 +1200
                        Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-17 07:19 +0100
                    Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:19 +0000
                      Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 08:29 +1200
                        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 18:49 -0700
                          Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 16:18 +1200
                            Re: Type system protocols rest atop fundamental data Öö Tiib <ootiib@hot.ee> - 2017-06-18 06:28 -0700
                  Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-16 09:11 -0700
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:04 +0200
              Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:56 +0000
                Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 07:10 -0700
                Re: Type system protocols rest atop fundamental data GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-16 16:38 +0200
                  Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 15:02 +0000
                    Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 08:11 -0700
                      Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:13 +0200
        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-14 14:42 -0700
    Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:32 +0100
      Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:28 -0700

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#112282

On Thursday, June 15, 2017 at 12:58:45 PM UTC-5, Scott Lurndal wrote:
> supercat writes:
> >If I were asked in the 1990s to describe the purpose of C's built-in types,
> >I would have described short as the shortest practical type with at least
> >16 bits, long as the most efficient type with at least 32 bits, and int as
> >the longest type between those whose computation cost is not significantly
> >greater than that of any shorter type in that range [in cases where
> >operations on 32-bit values would cost *slightly* more than those on 16-bit
> >values, int could be 16 bits, 32 bits, or configurable.]

> It should be obvious that the original types were designed specifically
> to support PDP-11 hardware. Nothing more, nothing less.

So far so good.

> By the 1990's, C was in widespread use by SGI (64-bit and 32-bit MIPS),
> SUN (64-bit SPARC), Motorola (680x0, 88100), Convergent (68k, i386),
> HP (PA-Risc), IBM (PowerPC, others) and several other smaller system
> houses.   Microsoft operating systems were pretty much irrelevent then.

I'm not sure why you regard Microsoft operating systems as irrelevant in
that time frame.  MS-DOS was the dominant personal computer operating
system in the late 1980s, and Windows turned a major corner around 1991.
Microsoft may have been a non-factor outside the realm of personal
computers, but much of the popularity of C stems from how well it fit the
architectures of personal computers (which were very similar in many ways
to the PDP-11).

It makes sense to say that if a platform doesn't have a type with exactly
16 bits, it could make "short" some other size like 18 bits.  There should
have been no real need for the Standard to specify what criteria to use
in deciding whether a certain size is practical, since in most platforms it
was pretty obvious.

> Amongst those vendors, there were variations on ILP64, LP64 and other
> mappings of the C type system to architectural fundamental types.  And
> of course, Microsoft had to be different from everyone else, when they
> finally got around to supporting 64-bit CPU's.

Microsoft recognized that there was no reason that compilers targeting
64-bit microcomputers shouldn't be able to run programs written either
specifically for 32-bit microcomputers, or written to be interchangeable
between 16-bit and 32-bit microcomputers.

[toc] | [prev] | [next] | [standalone]

#112283

supercat@casperkitty.com writes:
>On Thursday, June 15, 2017 at 12:58:45 PM UTC-5, Scott Lurndal wrote:
>> supercat writes:
>> >If I were asked in the 1990s to describe the purpose of C's built-in types,
>> >I would have described short as the shortest practical type with at least
>> >16 bits, long as the most efficient type with at least 32 bits, and int as
>> >the longest type between those whose computation cost is not significantly
>> >greater than that of any shorter type in that range [in cases where
>> >operations on 32-bit values would cost *slightly* more than those on 16-bit
>> >values, int could be 16 bits, 32 bits, or configurable.]
>
>> It should be obvious that the original types were designed specifically
>> to support PDP-11 hardware. Nothing more, nothing less.
>
>So far so good.
>
>> By the 1990's, C was in widespread use by SGI (64-bit and 32-bit MIPS),
>> SUN (64-bit SPARC), Motorola (680x0, 88100), Convergent (68k, i386),
>> HP (PA-Risc), IBM (PowerPC, others) and several other smaller system
>> houses.   Microsoft operating systems were pretty much irrelevent then.
>
>I'm not sure why you regard Microsoft operating systems as irrelevant in
>that time frame.  MS-DOS was the dominant personal computer operating

In the world of C programming, MS-DOS was irrelevent.

 [snip]
> [snip] but much of the popularity of C stems from how well it fit the
>architectures of personal computers (which were very similar in many ways
>to the PDP-11).

Wow, I can't believe you wrote that.

>
>Microsoft recognized that there was no reason that compilers targeting
>64-bit microcomputers shouldn't be able to run programs written either
>specifically for 32-bit microcomputers, or written to be interchangeable
>between 16-bit and 32-bit microcomputers.

Every other vendor using C disagreed.  Microsoft just went their
own way, like always and ignored the soi disant industry standard
of the time.   int64 instead of 64-bit long, really?

[toc] | [prev] | [next] | [standalone]

#112287

On Thursday, June 15, 2017 at 2:01:34 PM UTC-5, Scott Lurndal wrote:
> supercat writes:
> >I'm not sure why you regard Microsoft operating systems as irrelevant in
> >that time frame.  MS-DOS was the dominant personal computer operating
> 
> In the world of C programming, MS-DOS was irrelevent.

In the world of some snobs, personal computers were irrelevant, and
thus MS-DOS would have been likewise irrelevant.  In the personal
computer world, MS-DOS was dominant.


> > [snip] but much of the popularity of C stems from how well it fit the
> >architectures of personal computers (which were very similar in many ways
> >to the PDP-11).
> 
> Wow, I can't believe you wrote that.

The PDP-11, unlike most machines before it, but like the vast majority of
microcomputers that followed, had octets as the basic addressable unit of
storage.  The vast majority of non-8086 microcomputer implementations, or
8086 implementations set for "tiny", "small", or "medium" mode, used a
linear pointer representation such that if p and q are character pointers,
p-q will equal the difference in their integer representations.   Even
on "compact" or "large" mode 8086, p-q would yield the lower portion of
the difference in their representations (so if two objects were known to
be in the same segment one could do pointer arithmetic and comparisons
even if--from a language point of view--they were unrelated).

Many microcomputer implementations shared the downward-growing stack of
the PDP-11 along with the conventions of pushing arguments right to left
and having the caller clean up arguments.

Implementations could be big-endian or little-endian, could have int
be 16 bits, 32 bits, or configurable, and could have pointers that were
16 bits linear, 16+16 segmented, or 32 bits linear.  Aside from those
details, what other differences between a typical 1990s microcomputer
and a PDP-11 would a programmer have to worry about?

[toc] | [prev] | [next] | [standalone]

#112315

On 06/16/17 07:29 AM, supercat@casperkitty.com wrote:
> On Thursday, June 15, 2017 at 2:01:34 PM UTC-5, Scott Lurndal wrote:
>> supercat writes:
>>> I'm not sure why you regard Microsoft operating systems as irrelevant in
>>> that time frame.  MS-DOS was the dominant personal computer operating
>>
>> In the world of C programming, MS-DOS was irrelevent.
>
> In the world of some snobs, personal computers were irrelevant, and
> thus MS-DOS would have been likewise irrelevant.  In the personal
> computer world, MS-DOS was dominant.
>
>
>>> [snip] but much of the popularity of C stems from how well it fit the
>>> architectures of personal computers (which were very similar in many ways
>>> to the PDP-11).
>>
>> Wow, I can't believe you wrote that.
>
> The PDP-11, unlike most machines before it, but like the vast majority of
> microcomputers that followed, had octets as the basic addressable unit of
> storage.

The 68000 was way closer to the 8086 in its architecture (I programmed 
both PDP-11 and 68K at machine code level!).  The PC was almost, but not 
totally unlike the PDP-11.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#112319

On Thursday, June 15, 2017 at 8:47:41 PM UTC-5, Ian Collins wrote:
> The 68000 was way closer to the 8086 in its architecture (I programmed 
> both PDP-11 and 68K at machine code level!).  The PC was almost, but not 
> totally unlike the PDP-11.

The segmented model of the 8086 was unique; people loved to complain about it,
but code which was designed around it could be more efficient than code on
32-bit linear address machines (while PC code had a lot of 64K limitations,
the Macintosh had a lot of 32K limitations).

In any case, popular personal computers architectures were very consistent
with the PDP-11 in ways which were not required by the C Standard, but
were very useful for low-level microcomputer programming.  None of them
used ones'-complement, or memory that wasn't octet-addressable (some
DEC Alpha-based computers might have tried the latter, but I don't recall
them being exactly popular), or any of the other weird hardware quirks that
the Standard bent over backward to accommodate.

[toc] | [prev] | [next] | [standalone]

#112292

On Thursday, June 15, 2017 at 2:01:34 PM UTC-5, Scott Lurndal wrote:
> supercat writes:
> >Microsoft recognized that there was no reason that compilers targeting
> >64-bit microcomputers shouldn't be able to run programs written either
> >specifically for 32-bit microcomputers, or written to be interchangeable
> >between 16-bit and 32-bit microcomputers.
> 
> Every other vendor using C disagreed.  Microsoft just went their
> own way, like always and ignored the soi disant industry standard
> of the time.   int64 instead of 64-bit long, really?

Microsoft regarded implementations for 64-bit microcomputers as
microcomputer implementations, and saw no need to make them incompatible
with other such implementations.  Some other vendors may have seen 64-bit
microcomputers as repackaged "real computers", and not cared about what
anything had been doing with microcomputers, but Microsoft's key focus
all along had been with the computers that those other vendors were
ignoring, and with software written for those computers.

[toc] | [prev] | [next] | [standalone]

#112293

On Thursday, June 15, 2017 at 4:02:24 PM UTC-4, supe...@casperkitty.com wrote:
> Microsoft regarded implementations for 64-bit microcomputers as
> microcomputer implementations, and saw no need to make them incompatible
> with other such implementations ... Microsoft's key focus
> all along had been with the computers that those other vendors were
> ignoring, and with software written for those computers.

The Go Programming Language has taken a similar view with regards
to its assembly generation:

    https://talks.golang.org/2016/asm.slide#1
    https://www.youtube.com/watch?v=KINIAgRpkDA

Regardless of architecture, regardless of target ISA (32-bit or 64-
bit), they looked at reducing the assembly instruction set down to
its common factors, therefore being able to achieve multi-os, multi-
architecture compile targets with only a re-write of their assembly
generation module, so that it works with the intermediate language,
which then translates to the target CPU.

They're making great strides on this technology of making the asm
more independent of the architecture, while still keeping the bulk
of each architecture's utility and abilities in tact.

-----
Note:  This information comes from a post by Alexei A. Frounze on
       comp.lang.asm.x86:

    https://groups.google.com/d/msg/comp.lang.asm.x86/nMCgct2giyU/uuDV_WNABAAJ

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112294

On 15/06/17 22:02, supercat@casperkitty.com wrote:
> On Thursday, June 15, 2017 at 2:01:34 PM UTC-5, Scott Lurndal wrote:
>> supercat writes:
>>> Microsoft recognized that there was no reason that compilers targeting
>>> 64-bit microcomputers shouldn't be able to run programs written either
>>> specifically for 32-bit microcomputers, or written to be interchangeable
>>> between 16-bit and 32-bit microcomputers.
>>
>> Every other vendor using C disagreed.  Microsoft just went their
>> own way, like always and ignored the soi disant industry standard
>> of the time.   int64 instead of 64-bit long, really?
> 
> Microsoft regarded implementations for 64-bit microcomputers as
> microcomputer implementations, and saw no need to make them incompatible
> with other such implementations.  Some other vendors may have seen 64-bit
> microcomputers as repackaged "real computers", and not cared about what
> anything had been doing with microcomputers, but Microsoft's key focus
> all along had been with the computers that those other vendors were
> ignoring, and with software written for those computers.
> 

The kindest thing that could be said about MS's decision to make long 
32-bit in 64-bit mode is that they thought lots of existing Windows C 
code would make the assumption that long is always 32-bit, and so that 
choice would cause least breakage.

The least kind explanation is that this applied to their own code.

Either way, backwards compatibility with existing Windows C (or C++) 
code is the only sensible reason for having 32-bit longs in a 64-bit system.

(And Windows code that assumed a pointer could be stored in a "long" 
still broke.)

[toc] | [prev] | [next] | [standalone]

#112297

On Thursday, June 15, 2017 at 3:25:48 PM UTC-5, David Brown wrote:
> On 15/06/17 22:02, supercat wrote:
> The kindest thing that could be said about MS's decision to make long 
> 32-bit in 64-bit mode is that they thought lots of existing Windows C 
> code would make the assumption that long is always 32-bit, and so that 
> choice would cause least breakage.

C code for almost *any* microcomputer platform would have made such an
assumption prior to C99, since "long" was the closest thing to a fixed-
sized 32-bit type.  Many programs needed three sizes of integer, while
C defined a total of four types.  This allowed for one of C's types to
be regarded as implementation-dependent, and the other three to be
regarded as fixed size *among implementations targeting microcomputers*.

I'm not clear why code which wants something that's 32 bits on 32-bit
platforms and 64 bits on 64-bit platforms would want to use "long"
rather than something like size_t or ptrdiff_t, which would seem like
perfect types for that purpose.

> The least kind explanation is that this applied to their own code.

Their code is no worse in that regard than any other code written for
microcomputers prior to C99.

> Either way, backwards compatibility with existing Windows C (or C++) 
> code is the only sensible reason for having 32-bit longs in a 64-bit system.

Or any other C code written for microcomputers that doesn't rely upon C99
types.

> (And Windows code that assumed a pointer could be stored in a "long" 
> still broke.)

Microsoft could have handled compatibility better there, if they'd
remembered how things were done in 16-bit days.  Many programs use a
small amount of RAM frequently, and a large amount infrequently.  A
pointer with a "far" qualifier could access anything in memory, slowly,
while one with a "near" qualifier would be limited to accessing objects
that were within the primary 64K data segment.  A similar concept could
have been incorporated into 64-bit Windows--not trying to use "thunking"
in the style of segment-mode Windows (which never worked terribly well)
but by having special functions to request low-memory allocations, and
a means of converting 64-bit pointers to such allocations into 32-bit
pointers suitable for use with old APIs.

[toc] | [prev] | [next] | [standalone]

#112299

On 15/06/17 23:23, supercat@casperkitty.com wrote:
> On Thursday, June 15, 2017 at 3:25:48 PM UTC-5, David Brown wrote:
>> On 15/06/17 22:02, supercat wrote:
>> The kindest thing that could be said about MS's decision to make long
>> 32-bit in 64-bit mode is that they thought lots of existing Windows C
>> code would make the assumption that long is always 32-bit, and so that
>> choice would cause least breakage.
> 
> C code for almost *any* microcomputer platform would have made such an
> assumption prior to C99, since "long" was the closest thing to a fixed-
> sized 32-bit type.  Many programs needed three sizes of integer, while
> C defined a total of four types.  This allowed for one of C's types to
> be regarded as implementation-dependent, and the other three to be
> regarded as fixed size *among implementations targeting microcomputers*.
> 

C99 had been around for many years before MS started on 64-bit Windows - 
though MSVC certainly didn't support it.

But you are almost right - people used "long" to mean /at least/ 32-bit. 
  It is only those who write tightly platform-specific code that assumed 
it was always /exactly/ 32-bit.


> I'm not clear why code which wants something that's 32 bits on 32-bit
> platforms and 64 bits on 64-bit platforms would want to use "long"
> rather than something like size_t or ptrdiff_t, which would seem like
> perfect types for that purpose.

Yes, often these would be a better choice of type.

> 
>> The least kind explanation is that this applied to their own code.
> 
> Their code is no worse in that regard than any other code written for
> microcomputers prior to C99.

People had been writing code that worked on 16-bit, 32-bit and 64-bit 
for a good while before that.  64-bit entered the microcomputer 
mainstream in the mid 1990's.  (Cray had 64-bit data, but not 64-bit 
addresses, in 1976, and MIPS made their first 64-bit cpu in 1991.)  In 
the *nix world, C code that is portable between 32-bit and 64-bit 
predates C99 quite significantly.

> 
>> Either way, backwards compatibility with existing Windows C (or C++)
>> code is the only sensible reason for having 32-bit longs in a 64-bit system.
> 
> Or any other C code written for microcomputers that doesn't rely upon C99
> types.
> 
>> (And Windows code that assumed a pointer could be stored in a "long"
>> still broke.)
> 
> Microsoft could have handled compatibility better there, if they'd
> remembered how things were done in 16-bit days.  Many programs use a
> small amount of RAM frequently, and a large amount infrequently.  A
> pointer with a "far" qualifier could access anything in memory, slowly,
> while one with a "near" qualifier would be limited to accessing objects
> that were within the primary 64K data segment.  A similar concept could
> have been incorporated into 64-bit Windows--not trying to use "thunking"
> in the style of segment-mode Windows (which never worked terribly well)
> but by having special functions to request low-memory allocations, and
> a means of converting 64-bit pointers to such allocations into 32-bit
> pointers suitable for use with old APIs.
> 

The last thing anyone wanted or needed would be yet another way to 
access memory in different sized chunks and with programs having 
pointers of different sizes.  I am very glad that MS stuck to a linear 
addressing.  It is fair enough to choose to use 32-bit programs on a 
64-bit cpu, or to have an intermediary size like the x32 ABI (64-bit 
integers and all the 64-bit registers, but 32-bit addresses).  But 
mixing them within the same code is a terrible idea.

[toc] | [prev] | [next] | [standalone]

#112303

On Thursday, June 15, 2017 at 4:53:48 PM UTC-5, David Brown wrote:
> On 15/06/17 23:23, supercat wrote:
> But you are almost right - people used "long" to mean /at least/ 32-bit. 
>   It is only those who write tightly platform-specific code that assumed 
> it was always /exactly/ 32-bit.

A lot of microcomputer code has to interact with APIs that define data
structures in terms of physical layout.  Perhaps that was less common with
other kinds of computers, but in the microcomputer realm it was extremely
common, and it remains common in the embedded systems realm.

Further, I don't know about things outside the realm of microcomputers, but
within that realm platforms were extremely similar except for a few key
parameters (byte order, size of "int", pointer representation, and a few
details of floating-point operation).  Many other architectural aspects that
might have varied a lot among other kinds of computers were absolutely
consistent in the microcomputer realm.

> > Their code is no worse in that regard than any other code written for
> > microcomputers prior to C99.
> 
> People had been writing code that worked on 16-bit, 32-bit and 64-bit 
> for a good while before that.  64-bit entered the microcomputer 
> mainstream in the mid 1990's.  (Cray had 64-bit data, but not 64-bit 
> addresses, in 1976, and MIPS made their first 64-bit cpu in 1991.)  In 
> the *nix world, C code that is portable between 32-bit and 64-bit 
> predates C99 quite significantly.

The DEC Alpha came out in the early 1990s, but would hardly call that
mainstream.  What were you thinking of as a mainstream 64-bit microcomputer
platform in the mid 1990s?

> > Microsoft could have handled compatibility better there, if they'd
> > remembered how things were done in 16-bit days.  Many programs use a
> > small amount of RAM frequently, and a large amount infrequently.  A
> > pointer with a "far" qualifier could access anything in memory, slowly,
> > while one with a "near" qualifier would be limited to accessing objects
> > that were within the primary 64K data segment.  A similar concept could
> > have been incorporated into 64-bit Windows--not trying to use "thunking"
> > in the style of segment-mode Windows (which never worked terribly well)
> > but by having special functions to request low-memory allocations, and
> > a means of converting 64-bit pointers to such allocations into 32-bit
> > pointers suitable for use with old APIs.
> 
> The last thing anyone wanted or needed would be yet another way to 
> access memory in different sized chunks and with programs having 
> pointers of different sizes.  I am very glad that MS stuck to a linear 
> addressing.  It is fair enough to choose to use 32-bit programs on a 
> 64-bit cpu, or to have an intermediary size like the x32 ABI (64-bit 
> integers and all the 64-bit registers, but 32-bit addresses).  But 
> mixing them within the same code is a terrible idea.

If a program needs to use an external API (e.g. for communicating with an
I/O device, decoding audiovisual data, etc.) that expects to receive 32-bit
pointers, anything that will need to be accessible to that library will
need to be placed in a way that can be accessed by 32-bit pointers.  Simply
saying that any app which will need to do such a thing will be limited to
running in 32-bit mode may be simple, but would seem needlessly restrictive.

[toc] | [prev] | [next] | [standalone]

#112335

On 16/06/17 00:39, supercat@casperkitty.com wrote:
> On Thursday, June 15, 2017 at 4:53:48 PM UTC-5, David Brown wrote:
>> On 15/06/17 23:23, supercat wrote:
>> But you are almost right - people used "long" to mean /at least/ 32-bit. 
>>   It is only those who write tightly platform-specific code that assumed 
>> it was always /exactly/ 32-bit.
> 
> A lot of microcomputer code has to interact with APIs that define data
> structures in terms of physical layout.  Perhaps that was less common with
> other kinds of computers, but in the microcomputer realm it was extremely
> common, and it remains common in the embedded systems realm.
> 
> Further, I don't know about things outside the realm of microcomputers, but
> within that realm platforms were extremely similar except for a few key
> parameters (byte order, size of "int", pointer representation, and a few
> details of floating-point operation).  Many other architectural aspects that
> might have varied a lot among other kinds of computers were absolutely
> consistent in the microcomputer realm.

The microcomputer world settled pretty much on these things, yes.

> 
>>> Their code is no worse in that regard than any other code written for
>>> microcomputers prior to C99.
>>
>> People had been writing code that worked on 16-bit, 32-bit and 64-bit 
>> for a good while before that.  64-bit entered the microcomputer 
>> mainstream in the mid 1990's.  (Cray had 64-bit data, but not 64-bit 
>> addresses, in 1976, and MIPS made their first 64-bit cpu in 1991.)  In 
>> the *nix world, C code that is portable between 32-bit and 64-bit 
>> predates C99 quite significantly.
> 
> The DEC Alpha came out in the early 1990s, but would hardly call that
> mainstream.  What were you thinking of as a mainstream 64-bit microcomputer
> platform in the mid 1990s?
> 

Alpha, MIPS, PowerPC, Sparc all had 64-bit versions, and those were the
processors that dominated the *nix workstation and server markets.  The
x86 line as considered a cheap joke, for toys for games and office work
rather than for /real/ computing.  (Yes, there was more than a little
snobbery involved.)

These were all vastly nicer architectures, until Intel and AMD showed
the world that you really /can/ polish a turd, with very powerful
implementations of the mind-numbingly bad x86 architecture, and with the
economics of scale to push the good architectures pretty much out of
business.

[toc] | [prev] | [next] | [standalone]

#112347

On Friday, June 16, 2017 at 6:50:56 AM UTC-5, David Brown wrote:
> Alpha, MIPS, PowerPC, Sparc all had 64-bit versions, and those were the
> processors that dominated the *nix workstation and server markets.  The
> x86 line as considered a cheap joke, for toys for games and office work
> rather than for /real/ computing.  (Yes, there was more than a little
> snobbery involved.)

I consider those to exist in a separate universe from the microcomputers
that evolved from microprocessors (which were originally intended more as
replacements for logic, rather than as "computers").  While you may be
oblivious to anything that went on in the world of such "toys", C's dominance
in that world stemmed from the fact that a programmer armed with a simple
C compiler could exploit useful common features of those toys to produce
better code than was possible with competing languages.

C was always a better fit for microprocessors that can execute instructions
in any order at about the same speed, than for machines which require
extensive instruction re-ordering to achieve optimal performance.  I have
no long idea high-end computers have imposed what sorts of requirements, or
how long C compilers for such machines have imposed aggressive optimizations,
but such optimizations make high-end C a very different language from the
one that became popular for microcomputer programming in the 1990s.  It
should be possible to combine the best aspects of both evolutionary paths,
but only by acknowledging their differences.  Recognizing categories of
implementations that offer different levels of behavioral guarantees would
allow high-end compilers more freedom than they currently have, while at
the same time providing low-level programmers "official" access to the tools
they need to do their job efficiently.

[toc] | [prev] | [next] | [standalone]

#112467

On 16/06/17 17:40, supercat@casperkitty.com wrote:
> On Friday, June 16, 2017 at 6:50:56 AM UTC-5, David Brown wrote:
>> Alpha, MIPS, PowerPC, Sparc all had 64-bit versions, and those were the
>> processors that dominated the *nix workstation and server markets.  The
>> x86 line as considered a cheap joke, for toys for games and office work
>> rather than for /real/ computing.  (Yes, there was more than a little
>> snobbery involved.)
> 
> I consider those to exist in a separate universe from the microcomputers

A lot of your ideas seem to come from different universes...

> that evolved from microprocessors (which were originally intended more as
> replacements for logic, rather than as "computers").  While you may be
> oblivious to anything that went on in the world of such "toys", C's dominance
> in that world stemmed from the fact that a programmer armed with a simple
> C compiler could exploit useful common features of those toys to produce
> better code than was possible with competing languages.

First, my computer programming (as distinct from embedded programming) 
has mainly been on these "toys" - as the PC world was often viewed by 
with *nix world.  My university used Solaris workstations - these were 
way out of reach of our budget when I started work.  (Not that the tools 
I needed would run on them anyway.)

Second, PC's were /not/ programmed mainly in C - they were programming 
in assembly, or a variety of languages of which C was a minor option. 
Pascal, Basic, C++, dBase, and others were all popular as well, and 
often much more popular than C.  And the C used on DOS and Windows was 
not portable - it was DOS-C and Windows-C, full of assumptions about the 
platform and reliant on a range of extensions to handle the painful 
memory models and the awkward ABIs.  Part of the reason for the 
dominance of C in the *nix world, but not the PC world, was that it was 
relatively easy to get portability across systems despite wildly 
different cpu architectures and significant differences in the OS.

> 
> C was always a better fit for microprocessors that can execute instructions
> in any order at about the same speed, than for machines which require
> extensive instruction re-ordering to achieve optimal performance.

Nonsense.  It might be true about imaginary ideas of what you think C 
is, was, or should be, but it is not true of the actual C language of 
the standards, or the actual C implementations.

>  I have
> no long idea high-end computers have imposed what sorts of requirements, or
> how long C compilers for such machines have imposed aggressive optimizations,
> but such optimizations make high-end C a very different language from the
> one that became popular for microcomputer programming in the 1990s.  It
> should be possible to combine the best aspects of both evolutionary paths,
> but only by acknowledging their differences.  Recognizing categories of
> implementations that offer different levels of behavioral guarantees would
> allow high-end compilers more freedom than they currently have, while at
> the same time providing low-level programmers "official" access to the tools
> they need to do their job efficiently.
> 

[toc] | [prev] | [next] | [standalone]

#112602

On Sunday, June 18, 2017 at 9:49:51 AM UTC-5, David Brown wrote:
> On 16/06/17 17:40, supercat wrote:
> > I consider those to exist in a separate universe from the microcomputers
> 
> A lot of your ideas seem to come from different universes...

Since people who program microcomputers likely congregate around others who
do likewise, and the same could well be true of those who program high-end
computers, it is likely that the two groups of people would exist largely
independently.

> Second, PC's were /not/ programmed mainly in C - they were programming 
> in assembly, or a variety of languages of which C was a minor option. 
> Pascal, Basic, C++, dBase, and others were all popular as well, and 
> often much more popular than C.  And the C used on DOS and Windows was 
> not portable - it was DOS-C and Windows-C, full of assumptions about the 
> platform and reliant on a range of extensions to handle the painful 
> memory models and the awkward ABIs.  Part of the reason for the 
> dominance of C in the *nix world, but not the PC world, was that it was 
> relatively easy to get portability across systems despite wildly 
> different cpu architectures and significant differences in the OS.

DOS C allowed programs to be written in portable fashion, but programs that
made use of "near" and "far" qualifiers could be much more efficient than
code which didn't.  I never really looked into 16-bit Windows C since real
mode applications could be much more efficient than 16-bit protected-mode
applications.

Programming languages like Turbo Pascal (PC) and both MPW Pascal and
Think/Lightspeed Pascal (Macintosh) were more popular than C in the 1980s
but got displaced by C in the 1990s.  Applications like dBASE included
scripting languages that were used for many in-house applications, and
Microsoft made inroads with both QuickBasic and Visual BASIC, but C
allowed easy integration with assembly language and a program which was
written 95% in C and 5% in assembly language could achieve better
performance than most other languages.  Turbo Pascal might have held on
longer if it had included the ability to link to functions that used C
calling convention (Turbo C could call or generate code for either
convention).  When I wrote libraries I generally gave them all-caps names
that started with underscores and used the Pascal convention (making them
callable from either C or Pascal) but many other libraries only supported
the C convention.

> > C was always a better fit for microprocessors that can execute instructions
> > in any order at about the same speed, than for machines which require
> > extensive instruction re-ordering to achieve optimal performance.
> 
> Nonsense.  It might be true about imaginary ideas of what you think C 
> is, was, or should be, but it is not true of the actual C language of 
> the standards, or the actual C implementations.

Given something like:

    void copy_float_array(float *dest, float *src, int n)
    { memmove(dest, src, n*sizeof (float)); }

    int x;

    int test(float *dest, float *src, int n)
    { if (x)
      { x++; copy_float_array(dest, src, n); x--; }
      return x;
    }

a sequential-execution implementation would have no reason to know or care
whether the memmove would actually be operating upon things of type "float".
A high-end implementation would benefit greatly from knowing such things,
but C provides no means of conveying that information.  Do you not think a
good language for a high-end machines *should* provide such information?

C's effective type rules may be a reasonable fit for implementations that
would benefit from consolidate reads with previous reads or writes, but
not for those that would benefit from the ability to reorder writes.  Given:

   void test(int *ip, float *fp) { *ip = 12; *fp = 1.0f; }

the Standard would require that an implementation perform both writes in
the order given unless it has determined that the pointers target different
addresses.  I would think the language would be better suited for high-end
implementations if it would allow those operations to be re-ordered in the
absence of any evidence to suggest aliasing [e.g. of the code had been
written:

   void test(int *ip, int *fp) { *ip = 12; *((float*)fp) = 1.0f; }

the cast from "int*" to "float*" that occurs between the two writes would
be an example of evidence that aliasing should be expected, thus requiring
the operations to be performed in the order given].

[toc] | [prev] | [next] | [standalone]

#112605

supercat@casperkitty.com writes:
>On Sunday, June 18, 2017 at 9:49:51 AM UTC-5, David Brown wrote:

>> 
>> A lot of your ideas seem to come from different universes...
>

>Programming languages like Turbo Pascal (PC) and both MPW Pascal and
>Think/Lightspeed Pascal (Macintosh) were more popular than C in the 1980s

That's yet another idea from a different universe...

COBOL and FORTRAN were _much_ more popular than Pascal _or_ C
in the 1980's.

[toc] | [prev] | [next] | [standalone]

#112612

On Monday, June 19, 2017 at 12:50:44 PM UTC-5, Scott Lurndal wrote:
> >Programming languages like Turbo Pascal (PC) and both MPW Pascal and
> >Think/Lightspeed Pascal (Macintosh) were more popular than C in the 1980s
> 
> That's yet another idea from a different universe...
> 
> COBOL and FORTRAN were _much_ more popular than Pascal _or_ C
> in the 1980's.

Those languages were practically unknown in PC arena, which is what was
being discussed.  Prior to the introduction of Turbo Pascal, the only
common form of PC software development someone with floppies could use
without a multi-minute edit/build/run cycle was BASICA.  That allowed a
program to be executed without delay after editing it, but such execution
might be better described as "leisurely stroll" than "run".
 
Turbo Pascal could compile and run a thousand-line program in a fraction
of a minute and yield speed which for most code would only be about 2-3x
slower than hand-written assembly, and very quickly became popular, as
evidenced by the number of distributed executable programs that started
with a copy of Borland's runtime library.

I mentioned the Macintosh because it also had fast Pascal compilers before
it had a good C compiler, and as a consequence Pascal was popular there as
well as on the PC.

[toc] | [prev] | [next] | [standalone]

#112616

supercat@casperkitty.com writes:
>On Monday, June 19, 2017 at 12:50:44 PM UTC-5, Scott Lurndal wrote:
>> >Programming languages like Turbo Pascal (PC) and both MPW Pascal and
>> >Think/Lightspeed Pascal (Macintosh) were more popular than C in the 1980s
>> 
>> That's yet another idea from a different universe...
>> 
>> COBOL and FORTRAN were _much_ more popular than Pascal _or_ C
>> in the 1980's.
>
>Those languages were practically unknown in PC arena

Your claim was the 1980's.  Not the IBM PC.  Note that there
were a shitload of computers running in the 1980's, from the
TRS-80, the C64,the Amiga, PDP-11s, VAXs, Mainframes from
a dozen vendors - none of which had anything to
do with microsoft.  (And the Amiga _was_ programmed in C).

COBOL ran on the commodore 64 in 1985.  BASIC was far more popular
than any form of Pascal on the IBM PC in that era.

[toc] | [prev] | [next] | [standalone]

#112690

On 2017-06-19, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> Given something like:
>
>     void copy_float_array(float *dest, float *src, int n)
>     { memmove(dest, src, n*sizeof (float)); }
>
>     int x;
>
>     int test(float *dest, float *src, int n)
>     { if (x)
>       { x++; copy_float_array(dest, src, n); x--; }
>       return x;
>     }

Just curious: what's the purpose of the variable 'x' ?

[toc] | [prev] | [next] | [standalone]

#112701

On Tuesday, June 20, 2017 at 10:22:04 AM UTC-5, Ike Naar wrote:
> On 2017-06-19, supercat wrote:
> > Given something like:
> >
> >     void copy_float_array(float *dest, float *src, int n)
> >     { memmove(dest, src, n*sizeof (float)); }
> >
> >     int x;
> >
> >     int test(float *dest, float *src, int n)
> >     { if (x)
> >       { x++; copy_float_array(dest, src, n); x--; }
> >       return x;
> >     }
> 
> Just curious: what's the purpose of the variable 'x' ?

Consider what happens if either source or dest is (float*)&x.  As a more
specific example, consider:

    int evil_test(void)
    {
      int y;
      x=5;
      test((float*)&y, (float*)&x, 1);
      return y;
    }

If sizeof(float)==sizeof(int) [often the case], the call to
copy_float_array would perform a memmove(&y, &x, sizeof (int)), whose
behavior would be defined as copying x to y.  The only way a compiler
can uphold that behavior is either to have test() check whether src or
dest holds (float*)&x, or else execute the code as:

   load x
   add 1
   store x  
   do the move
   load x
   subtract 1
   store x
   return that value

rather than

   do the move
   load x
   return that value

Allowing for the possibility that src or dest might hold &x would force
the compiler to generate an extra add, subtract, and load, along with two
extra stores.  Note that if the function is used to move floating-point
values in cases where the source and destination could overlap, the src
and dest arguments could not be "restrict" qualified.

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web