Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #112176 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-06-14 06:14 -0700 |
| Last post | 2017-06-14 14:28 -0700 |
| Articles | 20 on this page of 106 — 19 participants |
Back to article view | Back to comp.lang.c
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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-16 12:05 -0700 |
| Message-ID | <16e06bd8-70d7-4632-bdc3-ffdc6c9f741b@googlegroups.com> |
| In reply to | #112335 |
On Friday, June 16, 2017 at 4:50:56 AM UTC-7, David Brown wrote: > 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. Curious - vastly nicer architectures. What metrics are you using to measure the niceness of computer architectures?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-16 12:30 -0700 |
| Message-ID | <f2e9eea4-906d-4d2a-8693-a1b3416ca99c@googlegroups.com> |
| In reply to | #112362 |
On Friday, June 16, 2017 at 2:05:54 PM UTC-5, David Kleinecke wrote: > On Friday, June 16, 2017 at 4:50:56 AM UTC-7, David Brown wrote: > > 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. > > Curious - vastly nicer architectures. What metrics are you using > to measure the niceness of computer architectures? They were nicer for some tasks, but not others. The DEC Alpha was unable to efficiently process writes of character-type data; for each byte, the processor would need to do a 32-bit or 64-bit load, some bit munging, and a 32-bit or 64-bit write. Such architectures also tended to have a looser memory-consistency model than x86 and x64. This allowed higher memory- access speeds, but increased the amount of explicit synchronization required, along with its associated overhead. More importantly, the only way to make code work reliably on a platform with a loose memory model is to design it around that model from the beginning. A system that uses a loose model will be unable to reliably handle code that's designed to run efficiently on existing computers that use a tighter model.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-18 16:54 +0200 |
| Message-ID | <oi640e$puk$1@dont-email.me> |
| In reply to | #112368 |
On 16/06/17 21:30, supercat@casperkitty.com wrote: > On Friday, June 16, 2017 at 2:05:54 PM UTC-5, David Kleinecke wrote: >> On Friday, June 16, 2017 at 4:50:56 AM UTC-7, David Brown wrote: >>> 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. >> >> Curious - vastly nicer architectures. What metrics are you using >> to measure the niceness of computer architectures? > > They were nicer for some tasks, but not others. The DEC Alpha was unable > to efficiently process writes of character-type data; for each byte, the > processor would need to do a 32-bit or 64-bit load, some bit munging, and > a 32-bit or 64-bit write. That was true of the first release, as it made the design a good deal simpler. Every Alpha after that allowed direct writes of different sizes. > Such architectures also tended to have a looser > memory-consistency model than x86 and x64. This allowed higher memory- > access speeds, but increased the amount of explicit synchronization required, > along with its associated overhead. Most architectures have looser memory consistency models than the x86 - with the result that it is far easier to scale the hardware. It turns out that it makes more sense to require a bit more effort in the synchronisation work, in order to make everything else more efficient and scalable. > More importantly, the only way to make > code work reliably on a platform with a loose memory model is to design it > around that model from the beginning. Hey, who would have thought it? To make synchronisation work, you need to know how it works. Amazing! > A system that uses a loose model will > be unable to reliably handle code that's designed to run efficiently on > existing computers that use a tighter model. > Again, another astounding revelation. Code written on the assumption of certain memory ordering guarantees will not work on platforms that don't guarantee these assumptions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-19 13:25 -0700 |
| Message-ID | <316e0ae4-9177-4b08-beb1-a1c54d40fa77@googlegroups.com> |
| In reply to | #112468 |
On Sunday, June 18, 2017 at 9:54:40 AM UTC-5, David Brown wrote: > On 16/06/17 21:30, supercat wrote: > > They were nicer for some tasks, but not others. The DEC Alpha was unable > > to efficiently process writes of character-type data; for each byte, the > > processor would need to do a 32-bit or 64-bit load, some bit munging, and > > a 32-bit or 64-bit write. > > That was true of the first release, as it made the design a good deal > simpler. Every Alpha after that allowed direct writes of different sizes. Fair enough. Before leaving the DEC Alpha, though, I should mention one concept from its documentation that could be usefully incorporated into a standard--*very* few operations yield behavior which is completely undefined. Instead, it uses other behavioral categories such as UNPREDICTABLE (written in allcaps, IIRC) with varying levels of associated guarantees. While the C Standard tends to favor simply saying "action X has undefined behavior" rather than identifying possible behaviors which could be chosen in Unspecified fashion, the latter approach would facilitate more optimizations than the former in cases where all possible behaviors would meet an application's requirements. > > Such architectures also tended to have a looser > > memory-consistency model than x86 and x64. This allowed higher memory- > > access speeds, but increased the amount of explicit synchronization required, > > along with its associated overhead. > > Most architectures have looser memory consistency models than the x86 - > with the result that it is far easier to scale the hardware. It turns > out that it makes more sense to require a bit more effort in the > synchronisation work, in order to make everything else more efficient > and scalable. Which kind of architecture is best depends upon how applications are designed and what they need to do. Some tasks can be accomplished much more practically using "non-scalable" approaches than using scalable ones. Further, if one has a system that *works* and was designed around a memory model that could be processed efficiently with an earlier generation of hardware, new hardware that can make the same code work a little faster may be much more useful than hardware which could perform the same task twenty times as fast, but would require a complete rewrite of the code. > > More importantly, the only way to make > > code work reliably on a platform with a loose memory model is to design it > > around that model from the beginning. > > Hey, who would have thought it? To make synchronisation work, you need > to know how it works. Amazing! On a system that uses write-through caches, implementing a strong memory model costs almost nothing extra compared with implementing a weak one. Code written for a weak model well be more complicated and less efficient than code written for a strong model, when run on a platform that could support either. If one knows that systems which use a tight memory model won't be available in the future, then it might make sense to design a program for a loose model even if one's present machine could support a tight model at no extra charge. If, however, one's present machine has a tight model and there's no reason to believe one won't be able to get a replacement which also has a tight model, writing code for the tight model would seem a perfectly reasonable engineering decision. I see no basis for your smug attitude.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 09:27 +0200 |
| Message-ID | <oiaihc$vdl$1@dont-email.me> |
| In reply to | #112629 |
On 19/06/17 22:25, supercat@casperkitty.com wrote: > On Sunday, June 18, 2017 at 9:54:40 AM UTC-5, David Brown wrote: >> On 16/06/17 21:30, supercat wrote: >>> They were nicer for some tasks, but not others. The DEC Alpha was unable >>> to efficiently process writes of character-type data; for each byte, the >>> processor would need to do a 32-bit or 64-bit load, some bit munging, and >>> a 32-bit or 64-bit write. >> >> That was true of the first release, as it made the design a good deal >> simpler. Every Alpha after that allowed direct writes of different sizes. > > Fair enough. Before leaving the DEC Alpha, though, I should mention one > concept from its documentation that could be usefully incorporated into a > standard--*very* few operations yield behavior which is completely undefined. > Instead, it uses other behavioral categories such as UNPREDICTABLE (written > in allcaps, IIRC) with varying levels of associated guarantees. > > While the C Standard tends to favor simply saying "action X has undefined > behavior" rather than identifying possible behaviors which could be chosen > in Unspecified fashion, the latter approach would facilitate more > optimizations than the former in cases where all possible behaviors would > meet an application's requirements. You would like some cases where the standards today say "undefined behaviour" to be replaced by "unpredictable results"? Such as saying that if you add two integers that overflow, then instead of being undefined behaviour it should result in an integer whose value is unpredictable? Basically, that would be the same as "unspecified". I can see that appealing to you - but it would not appeal to me in general. It would let you write some kinds of code a little faster, but also block many other optimisations. In the quest for ever-faster code, I would prefer to be able to /explicitly/ tell the compiler that something is unspecified. This would almost certainly be an implementation extension. But being able to assign or return a value of "__builtin_dontcare", which would let the compiler use whatever value it finds most useful for optimisation, would let you write your faster code. > >>> Such architectures also tended to have a looser >>> memory-consistency model than x86 and x64. This allowed higher memory- >>> access speeds, but increased the amount of explicit synchronization required, >>> along with its associated overhead. >> >> Most architectures have looser memory consistency models than the x86 - >> with the result that it is far easier to scale the hardware. It turns >> out that it makes more sense to require a bit more effort in the >> synchronisation work, in order to make everything else more efficient >> and scalable. > > Which kind of architecture is best depends upon how applications are > designed and what they need to do. Some tasks can be accomplished much > more practically using "non-scalable" approaches than using scalable ones. > Yes, of course. > > On a system that uses write-through caches, implementing a strong memory > model costs almost nothing extra compared with implementing a weak one. > Code written for a weak model well be more complicated and less efficient > than code written for a strong model, when run on a platform that could > support either. That may be true. But (almost) no system where you would have multiple processors - which is where the strength of the memory model is important - would have write-through caches. That would cripple performance. > > If one knows that systems which use a tight memory model won't be available > in the future, then it might make sense to design a program for a loose > model even if one's present machine could support a tight model at no extra > charge. If, however, one's present machine has a tight model and there's no > reason to believe one won't be able to get a replacement which also has a > tight model, writing code for the tight model would seem a perfectly > reasonable engineering decision. I see no basis for your smug attitude. > You mean, because so many people are used to writing sloppy code for x86 machines, we can expect that x86 systems will be with us for many years to come? Yes, there is some truth in that.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-20 08:53 -0700 |
| Message-ID | <64822b00-b983-4b36-be6d-27167aa918eb@googlegroups.com> |
| In reply to | #112668 |
On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: > You would like some cases where the standards today say "undefined > behaviour" to be replaced by "unpredictable results"? Such as saying > that if you add two integers that overflow, then instead of being > undefined behaviour it should result in an integer whose value is > unpredictable? Basically, that would be the same as "unspecified". Yes, though I would allow implementations to also specify either that integer overflows will (pick one): 1. Always trigger a trap, whether or not the results are used. 2. Always trigger a trap in cases where a program's behavior could not be guaranteed the same as if computations were performed in arithmetically correct fashion, and arbitrarily trap or not in other cases where overflow occurs but the program would behave as though computations were performed in arithmetically-correct fashion. 3. Arbitrarily trap or not when overflows occur. 4. Never trap when overflows occur. and--in cases where execution could continue after an overflow that might result in arithmetically-incorrect output, also select one of: A. Always truncate all computations to the size of "int". B. Process intermediate results with any convenient level of precision beyond "int", but truncate results when stored in variables. C. Treat any computation that overflows as though it may have arbitrary "wobbly" upper bits, even when stored in a variable, unless converted to another type or explicitly cast to its own type [the latter being analogous to casting a "float" expression to float to force rounding]. If a program needs to ensure that it doesn't produce seemingly-valid-but- wrong results in case of overflow, having a compiler guarantee #2 could yield much faster results than trying to provide such assurance entirely in user code. If a program needs to compute a number of values some of which will be ignored by some callers, unconditionally computing them all may be faster than trying to be selective, and under semantic #C would be perfectly safe even if overflows could occur in the otherwise-ignored calculations. > I can see that appealing to you - but it would not appeal to me in > general. It would let you write some kinds of code a little faster, but > also block many other optimisations. In the quest for ever-faster code, > I would prefer to be able to /explicitly/ tell the compiler that > something is unspecified. This would almost certainly be an > implementation extension. But being able to assign or return a value of > "__builtin_dontcare", which would let the compiler use whatever value it > finds most useful for optimisation, would let you write your faster code. If a program's behavioral requirements when given invalid data are extremely tight, would makes sense for code that handles invalid data to be larger and more complicated than the code to handle valid data. If the requirements are basically "either compute some arbitrary value with no side-effects or flag an error, as convenient", meeting those requirements should be cheap and easy. > > Which kind of architecture is best depends upon how applications are > > designed and what they need to do. Some tasks can be accomplished much > > more practically using "non-scalable" approaches than using scalable ones. > > Yes, of course. > > On a system that uses write-through caches, implementing a strong memory > > model costs almost nothing extra compared with implementing a weak one. > > Code written for a weak model well be more complicated and less efficient > > than code written for a strong model, when run on a platform that could > > support either. > > That may be true. But (almost) no system where you would have multiple > processors - which is where the strength of the memory model is > important - would have write-through caches. That would cripple > performance. Microprocessor systems started including dual processors before processors started including write-back caches (or, for that matter, any data caches). A write-through cache is no good for a processor that's running multiple instructions per clock cycle, hooked up to memory that takes dozens of cycles to access, but it's just the ticket for a processor that takes at least a cycle per instruction, hooked up to memory that takes 3-4 cycles to access. In addition, interactive applications can often benefit from multi-threading even on a single CPU, which of course could offer an absolutely consistent memory model at no extra charge. I find it curious that there isn't more effort to make it easy for programs to specify groups of threads that need to have a strong memory model *with respect to each other*. If a system has enough different independent tasks to perform to keep all the cores busy, ensuring that certain threads are only performed on cores within the same memory subsystem should cost very little, but would allow those threads to exchange data among themselves more cheaply than if they had to use memory synchronization methods. An interlocked compare-exchange that needs to be atomic among cores connected through a slow bus is expensive, but one that was local to a single caching system can be much cheap. > > If one knows that systems which use a tight memory model won't be available > > in the future, then it might make sense to design a program for a loose > > model even if one's present machine could support a tight model at no extra > > charge. If, however, one's present machine has a tight model and there's no > > reason to believe one won't be able to get a replacement which also has a > > tight model, writing code for the tight model would seem a perfectly > > reasonable engineering decision. I see no basis for your smug attitude. > > You mean, because so many people are used to writing sloppy code for x86 > machines, we can expect that x86 systems will be with us for many years > to come? Yes, there is some truth in that. A machine which has groups of cores which have a tight memory models internally, but have a loose memory model connecting them, could offer a good migration path forward if combined with an OS that would by default ensure that any particular process would see a tight memory model. If e.g. typical machines have groups of four cores joined by a tight model, people writing new applications could design them so they could run on multiple loosely-linked cores without difficulty. Adding more groups of cores may not help the performance of old applications, but if an application ran plenty fast on the old machine being able to run it the same way on the new machine may be just fine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 22:12 +0200 |
| Message-ID | <oibvcq$p2c$1@dont-email.me> |
| In reply to | #112696 |
On 20/06/17 17:53, supercat@casperkitty.com wrote: > On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: >> You would like some cases where the standards today say "undefined >> behaviour" to be replaced by "unpredictable results"? Such as saying >> that if you add two integers that overflow, then instead of being >> undefined behaviour it should result in an integer whose value is >> unpredictable? Basically, that would be the same as "unspecified". > > Yes, though I would allow implementations to also specify either that > integer overflows will (pick one): > > 1. Always trigger a trap, whether or not the results are used. > > 2. Always trigger a trap in cases where a program's behavior could not be > guaranteed the same as if computations were performed in arithmetically > correct fashion, and arbitrarily trap or not in other cases where overflow > occurs but the program would behave as though computations were performed > in arithmetically-correct fashion. > > 3. Arbitrarily trap or not when overflows occur. > > 4. Never trap when overflows occur. > > and--in cases where execution could continue after an overflow that might > result in arithmetically-incorrect output, also select one of: > > A. Always truncate all computations to the size of "int". > > B. Process intermediate results with any convenient level of precision > beyond "int", but truncate results when stored in variables. > > C. Treat any computation that overflows as though it may have arbitrary > "wobbly" upper bits, even when stored in a variable, unless converted > to another type or explicitly cast to its own type [the latter being > analogous to casting a "float" expression to float to force rounding]. They can do that today. "Undefined behaviour" means that the C standard does not define the behaviour. It does not mean that the implementation may /not/ define the behaviour. >>> On a system that uses write-through caches, implementing a strong memory >>> model costs almost nothing extra compared with implementing a weak one. >>> Code written for a weak model well be more complicated and less efficient >>> than code written for a strong model, when run on a platform that could >>> support either. >> >> That may be true. But (almost) no system where you would have multiple >> processors - which is where the strength of the memory model is >> important - would have write-through caches. That would cripple >> performance. > > Microprocessor systems started including dual processors before processors > started including write-back caches (or, for that matter, any data caches). Dual processor systems were very rare before caches. But even if they existed historically, they are irrelevant to the point here. > A write-through cache is no good for a processor that's running multiple > instructions per clock cycle, hooked up to memory that takes dozens of cycles > to access, but it's just the ticket for a processor that takes at least a > cycle per instruction, hooked up to memory that takes 3-4 cycles to access. No, it is not. The cost is not as bad, but it is still slower to have write-through except perhaps for parts of memory that are very likely to be shared. Your memory quickly becomes a bottleneck even with one processor on such a system - with two, it is worse. (I have worked with a dual processor microcontroller with timings much like that. It is not idle speculation - using write-through instead of write-back is daft except for special circumstances such as memory areas that are strongly shared between the processors or other bus masters.) > > In addition, interactive applications can often benefit from multi-threading > even on a single CPU, which of course could offer an absolutely consistent > memory model at no extra charge. Within a single cpu, you have a strong memory model, yes. Writing code that works for a weak memory model is not /that/ much harder than writing code for a strong memory model - nor is it /that/ much less efficient. You still need fences for Store-Load cases. And for most people in most circumstances, you use the macros, function calls, etc., from your OS, or you use C11/C++11 atomics, or you use locks. Load-Load, Store-Store and Load-Store fences will reduce to nothing or compiler barriers on strong memory model processors, and appropriate cpu instructions on weak memory model processors.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-06-20 13:14 -0700 |
| Message-ID | <oibvgq$pj7$1@dont-email.me> |
| In reply to | #112735 |
On 6/20/2017 1:12 PM, David Brown wrote: > On 20/06/17 17:53, supercat@casperkitty.com wrote: >> On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: >>> You would like some cases where the standards today say "undefined >>> behaviour" to be replaced by "unpredictable results"? Such as saying >>> that if you add two integers that overflow, then instead of being >>> undefined behaviour it should result in an integer whose value is >>> unpredictable? Basically, that would be the same as "unspecified". >> >> Yes, though I would allow implementations to also specify either that >> integer overflows will (pick one): >> >> 1. Always trigger a trap, whether or not the results are used. >> >> 2. Always trigger a trap in cases where a program's behavior could not be >> guaranteed the same as if computations were performed in >> arithmetically >> correct fashion, and arbitrarily trap or not in other cases where >> overflow >> occurs but the program would behave as though computations were >> performed >> in arithmetically-correct fashion. >> >> 3. Arbitrarily trap or not when overflows occur. >> >> 4. Never trap when overflows occur. >> >> and--in cases where execution could continue after an overflow that might >> result in arithmetically-incorrect output, also select one of: >> >> A. Always truncate all computations to the size of "int". >> >> B. Process intermediate results with any convenient level of precision >> beyond "int", but truncate results when stored in variables. >> >> C. Treat any computation that overflows as though it may have arbitrary >> "wobbly" upper bits, even when stored in a variable, unless converted >> to another type or explicitly cast to its own type [the latter being >> analogous to casting a "float" expression to float to force >> rounding]. > > They can do that today. "Undefined behaviour" means that the C standard > does not define the behaviour. It does not mean that the implementation > may /not/ define the behaviour. > >>>> On a system that uses write-through caches, implementing a strong >>>> memory >>>> model costs almost nothing extra compared with implementing a weak one. >>>> Code written for a weak model well be more complicated and less >>>> efficient >>>> than code written for a strong model, when run on a platform that could >>>> support either. >>> >>> That may be true. But (almost) no system where you would have multiple >>> processors - which is where the strength of the memory model is >>> important - would have write-through caches. That would cripple >>> performance. >> >> Microprocessor systems started including dual processors before >> processors >> started including write-back caches (or, for that matter, any data >> caches). > > Dual processor systems were very rare before caches. But even if they > existed historically, they are irrelevant to the point here. > >> A write-through cache is no good for a processor that's running multiple >> instructions per clock cycle, hooked up to memory that takes dozens of >> cycles >> to access, but it's just the ticket for a processor that takes at least a >> cycle per instruction, hooked up to memory that takes 3-4 cycles to >> access. > > No, it is not. The cost is not as bad, but it is still slower to have > write-through except perhaps for parts of memory that are very likely to > be shared. Your memory quickly becomes a bottleneck even with one > processor on such a system - with two, it is worse. > > (I have worked with a dual processor microcontroller with timings much > like that. It is not idle speculation - using write-through instead of > write-back is daft except for special circumstances such as memory areas > that are strongly shared between the processors or other bus masters.) > >> >> In addition, interactive applications can often benefit from >> multi-threading >> even on a single CPU, which of course could offer an absolutely >> consistent >> memory model at no extra charge. > > Within a single cpu, you have a strong memory model, yes. > > Writing code that works for a weak memory model is not /that/ much > harder than writing code for a strong memory model - nor is it /that/ > much less efficient. You still need fences for Store-Load cases. And > for most people in most circumstances, you use the macros, function > calls, etc., from your OS, or you use C11/C++11 atomics, or you use > locks. Load-Load, Store-Store and Load-Store fences will reduce to > nothing or compiler barriers on strong memory model processors, and > appropriate cpu instructions on weak memory model processors. > Love the SPARC RMO mode!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-06-20 13:16 -0700 |
| Message-ID | <oibvkl$pj7$2@dont-email.me> |
| In reply to | #112736 |
On 6/20/2017 1:14 PM, Chris M. Thomasson wrote: > On 6/20/2017 1:12 PM, David Brown wrote: >> On 20/06/17 17:53, supercat@casperkitty.com wrote: >>> On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: [...] >> Writing code that works for a weak memory model is not /that/ much >> harder than writing code for a strong memory model - nor is it /that/ >> much less efficient. You still need fences for Store-Load cases. And >> for most people in most circumstances, you use the macros, function >> calls, etc., from your OS, or you use C11/C++11 atomics, or you use >> locks. Load-Load, Store-Store and Load-Store fences will reduce to >> nothing or compiler barriers on strong memory model processors, and >> appropriate cpu instructions on weak memory model processors. >> > > Love the SPARC RMO mode! Also, lets not forget about the Alpha where dependent loads are not honored without explicit membar. Fun times!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-20 14:04 -0700 |
| Message-ID | <84c41593-bee7-4081-8685-56ab68b587fd@googlegroups.com> |
| In reply to | #112735 |
On Tuesday, June 20, 2017 at 3:12:45 PM UTC-5, David Brown wrote: > On 20/06/17 17:53, supercat wrote: > > On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: > >> You would like some cases where the standards today say "undefined > >> behaviour" to be replaced by "unpredictable results"? Such as saying > >> that if you add two integers that overflow, then instead of being > >> undefined behaviour it should result in an integer whose value is > >> unpredictable? Basically, that would be the same as "unspecified". > > > > Yes, though I would allow implementations to also specify either that > > integer overflows will (pick one): > They can do that today. "Undefined behaviour" means that the C standard > does not define the behaviour. It does not mean that the implementation > may /not/ define the behaviour. So if I want to write a program that will only compile on implementations that can uphold promises #4 and #B, how would I do that? > > Microprocessor systems started including dual processors before processors > > started including write-back caches (or, for that matter, any data caches). > > Dual processor systems were very rare before caches. But even if they > existed historically, they are irrelevant to the point here. Such things were rare, but microprocessors entered the multi-processing world with strong-memory-model systems. High-end multi-processor systems may have used looser memory models from the get-go, but microprocessor-based systems didn't. > > A write-through cache is no good for a processor that's running multiple > > instructions per clock cycle, hooked up to memory that takes dozens of cycles > > to access, but it's just the ticket for a processor that takes at least a > > cycle per instruction, hooked up to memory that takes 3-4 cycles to access. > > No, it is not. The cost is not as bad, but it is still slower to have > write-through except perhaps for parts of memory that are very likely to > be shared. Your memory quickly becomes a bottleneck even with one > processor on such a system - with two, it is worse. A write-through cache is considerably cheaper than a write-back cache, and can support things like DMA without requiring software changes. On a system with a write-back cache, software compatibility with DMA would require that a processor be able to monitor DMA requests, recognize attempts by an external device to fetch memory which is dirty, and substitute cache data for data from main RAM. Rather complicated. By contrast, on a system with a write- through cache, all the processor would need to do is invalidate any cache lines whose addresses get hit by DMA writes. For most kinds of programs, the vast majority of memory accesses will be code fetches, and the majority of the remainder will be memory reads. If main-bus operations cost dozens of cycles, the savings from a write-back cache may be sufficient to justify the cost, but if they only cost 3-4 cycles, money that could be spent on a write-back cache could likely better be spent elsewhere. > (I have worked with a dual processor microcontroller with timings much > like that. It is not idle speculation - using write-through instead of > write-back is daft except for special circumstances such as memory areas > that are strongly shared between the processors or other bus masters.) If hardware exists to support both, sure. At the microcontroller level, until one gets beyond 4 cores or so, I would think the best bang for the buck would be achieved by having at least one memory bus per controller with a region of RAM attached to it, and then have code try to place things so that different controllers operate in different memory regions to the extent possible. A lot of controllers seem able to perform simultaneous DMA and CPU fetches from disjoint areas of address space, so doing likewise with two CPU cores shouldn't be a problem. > > In addition, interactive applications can often benefit from multi-threading > > even on a single CPU, which of course could offer an absolutely consistent > > memory model at no extra charge. > > Within a single cpu, you have a strong memory model, yes. > > Writing code that works for a weak memory model is not /that/ much > harder than writing code for a strong memory model - nor is it /that/ > much less efficient. You still need fences for Store-Load cases. And > for most people in most circumstances, you use the macros, function > calls, etc., from your OS, or you use C11/C++11 atomics, or you use > locks. Load-Load, Store-Store and Load-Store fences will reduce to > nothing or compiler barriers on strong memory model processors, and > appropriate cpu instructions on weak memory model processors. If one is designing an application from scratch to run efficiently on many processors simultaneously, it would make sense to design it around a loose memory model. If one is tasked with maintaining an existing application which was designed around a tight memory model, and if performance isn't an issue, staying with a tight memory model would seem safer than trying to rework everything for a loose one. Inserting barriers may not be hard, but ensuring that one hasn't missed any places where they're required may be another story.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-21 15:33 +0200 |
| Message-ID | <oidscf$92j$1@dont-email.me> |
| In reply to | #112764 |
On 20/06/17 23:04, supercat@casperkitty.com wrote: > On Tuesday, June 20, 2017 at 3:12:45 PM UTC-5, David Brown wrote: >> On 20/06/17 17:53, supercat wrote: >>> On Tuesday, June 20, 2017 at 2:27:23 AM UTC-5, David Brown wrote: >>>> You would like some cases where the standards today say "undefined >>>> behaviour" to be replaced by "unpredictable results"? Such as saying >>>> that if you add two integers that overflow, then instead of being >>>> undefined behaviour it should result in an integer whose value is >>>> unpredictable? Basically, that would be the same as "unspecified". >>> >>> Yes, though I would allow implementations to also specify either that >>> integer overflows will (pick one): > >> They can do that today. "Undefined behaviour" means that the C standard >> does not define the behaviour. It does not mean that the implementation >> may /not/ define the behaviour. > > So if I want to write a program that will only compile on implementations > that can uphold promises #4 and #B, how would I do that? Only use implementations that can uphold promises #4 and #8 (whatever they were) to compile your code. An implementation can add any extra guarantees it wants beyond the standard - that is the choice of the implementer. A programmer can require additional guarantees for their code to be correct - that is the choice of the programmer. > >>> Microprocessor systems started including dual processors before processors >>> started including write-back caches (or, for that matter, any data caches). >> >> Dual processor systems were very rare before caches. But even if they >> existed historically, they are irrelevant to the point here. > > Such things were rare, but microprocessors entered the multi-processing > world with strong-memory-model systems. High-end multi-processor systems > may have used looser memory models from the get-go, but microprocessor-based > systems didn't. I think you are making up your own terms, your own distinctions about what counts as a "processor" and what counts as a "microprocessor" (there is no fixed definition), and your own history here. It is possible that you are coincidentally correct, but it is all totally /irrelevant/. It does not /matter/ if the first SMP system had strong or weak memory models, or write-back or write-through caches or no caches at all. The facts are simple: 1. On all realistic SMP systems, write-through cache would be a bottleneck and a significant hinder to performance. Therefore it is rarely used on SMP systems. 2. Strong memory models are expensive to implement on most systems, and scale badly when sizes increase. Therefore most processors have weaker memory models. 3. Writing code that is correct for a weak memory model is not much harder than writing code that is correct for a strong memory model, in the way that most people write code. It might be harder for the OS developers and the folks writing the implementations of atomic access libraries, but they are not "most people". > >>> A write-through cache is no good for a processor that's running multiple >>> instructions per clock cycle, hooked up to memory that takes dozens of cycles >>> to access, but it's just the ticket for a processor that takes at least a >>> cycle per instruction, hooked up to memory that takes 3-4 cycles to access. >> >> No, it is not. The cost is not as bad, but it is still slower to have >> write-through except perhaps for parts of memory that are very likely to >> be shared. Your memory quickly becomes a bottleneck even with one >> processor on such a system - with two, it is worse. > > A write-through cache is considerably cheaper than a write-back cache, and > can support things like DMA without requiring software changes. No it cannot. I have worked on these things, and know the issues. Having a write-through cache does /not/ mean that you get all the data out to memory, as seen by the DMA, at the time you might expect. You still have to use compiler memory barriers and appropriate processor data synchronisation instructions to ensure data has hit the memory before you start the DMA. You may need additional setup or instructions to handle re-ordering in memory write buffers, DDR controllers, etc. And you still need cache control for when you are reading back data that is written by DMA. Having write-back cache means that when sending data /to/ the DMA memory, you also need cache flush instructions. But that is just one more out of the half-dozen things you need to remember and get write - it does not make an easy task hard, it merely makes a hard task marginally harder. > On a system > with a write-back cache, software compatibility with DMA would require that a > processor be able to monitor DMA requests, recognize attempts by an external > device to fetch memory which is dirty, and substitute cache data for data > from main RAM. Rather complicated. Actually, it is quite simple. It is just cache snooping, something that is common on SMP processors.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-20 13:25 +0000 |
| Message-ID | <Gn92B.25287$Jz4.2422@fx21.iad> |
| In reply to | #112629 |
supercat@casperkitty.com writes: >On Sunday, June 18, 2017 at 9:54:40 AM UTC-5, David Brown wrote: >> On 16/06/17 21:30, supercat wrote: >> > They were nicer for some tasks, but not others. The DEC Alpha was unable >> > to efficiently process writes of character-type data; for each byte, the >> > processor would need to do a 32-bit or 64-bit load, some bit munging, and >> > a 32-bit or 64-bit write. >> >> That was true of the first release, as it made the design a good deal >> simpler. Every Alpha after that allowed direct writes of different sizes. > >Fair enough. Before leaving the DEC Alpha, though, I should mention one >concept from its documentation that could be usefully incorporated into a >standard--*very* few operations yield behavior which is completely undefined. >Instead, it uses other behavioral categories such as UNPREDICTABLE (written >in allcaps, IIRC) with varying levels of associated guarantees. > >While the C Standard tends to favor simply saying "action X has undefined >behavior" rather than identifying possible behaviors which could be chosen >in Unspecified fashion, the latter approach would facilitate more >optimizations than the former in cases where all possible behaviors would >meet an application's requirements. One must be cautious when comparing a language standard with the description of a processor architectural implementation. Apples != Oranges. > >On a system that uses write-through caches, implementing a strong memory >model costs almost nothing extra compared with implementing a weak one. >Code written for a weak model well be more complicated and less efficient >than code written for a strong model, when run on a platform that could >support either. Yet a write-through cache doesn't perform as well as a write-back cache for most general workloads due to memory bandwidth limitations, which is why everybody uses write-back (there are some vendors whose L1D cache is write-through into L2, these are generally VIVT or VIPT caches). There are also some networking workloads where write-through makes sense for access-once data (and for that x86 et alia offer non-temporal instructions).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-16 19:42 +0000 |
| Message-ID | <nwW0B.27516$c46.20414@fx03.iad> |
| In reply to | #112362 |
David Kleinecke <dkleinecke@gmail.com> writes: >On Friday, June 16, 2017 at 4:50:56 AM UTC-7, 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.) >> >> 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. > >Curious - vastly nicer architectures. What metrics are you using >to measure the niceness of computer architectures? Ease of implementation?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-18 16:58 +0200 |
| Message-ID | <oi647b$qjs$1@dont-email.me> |
| In reply to | #112362 |
On 16/06/17 21:05, David Kleinecke wrote: > On Friday, June 16, 2017 at 4:50:56 AM UTC-7, 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.) >> >> 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. > > Curious - vastly nicer architectures. What metrics are you using > to measure the niceness of computer architectures? > Obviously it is a highly subjective measure. In my opinion, it means orthogonal instruction sets, plenty of registers, predictable execution, minimal instruction dependencies (i.e., condition codes should be optional), scalable architectures, etc. This leads to efficient and powerful implementations, and solid compilers.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-17 19:18 +0000 |
| Message-ID | <59457ff9.5153343@news.xs4all.nl> |
| In reply to | #112335 |
David Brown <david.brown@hesbynett.no> 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.) Was? > 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. Still is, clearly. AlphaNix four legs good, Wintel two legs BAAAHD. Bleat on, comrade. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-06-15 23:40 -0500 |
| Message-ID | <pqn6kcpptptnc49n25967r0j6kgqq4cd6q@4ax.com> |
| In reply to | #112299 |
On Thu, 15 Jun 2017 23:53:27 +0200, David Brown <david.brown@hesbynett.no> wrote: >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. FWIW: MS released the first 64-bit version of XP in 2001 (for IPF), so not really "many" years. Usage was pretty minimal, though. MS did most of the early 64-bit porting work for Windows on Alpha, although that was never released, and even the (32-bit) Alpha version of Win2K died just before the actual release.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-16 13:51 +0200 |
| Message-ID | <oi0gi3$85e$2@dont-email.me> |
| In reply to | #112326 |
On 16/06/17 06:40, Robert Wessel wrote: > On Thu, 15 Jun 2017 23:53:27 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> 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. > > > FWIW: > > MS released the first 64-bit version of XP in 2001 (for IPF), so not > really "many" years. Usage was pretty minimal, though. I'd forgotten about the Itanium. Both Microsoft and Intel wish the rest of the world would follow suit :-) > > MS did most of the early 64-bit porting work for Windows on Alpha, > although that was never released, and even the (32-bit) Alpha version > of Win2K died just before the actual release. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-16 12:55 +0000 |
| Message-ID | <dzQ0B.43966$IX3.2276@fx19.iad> |
| In reply to | #112336 |
David Brown <david.brown@hesbynett.no> writes: >On 16/06/17 06:40, Robert Wessel wrote: >> MS released the first 64-bit version of XP in 2001 (for IPF), so not >> really "many" years. Usage was pretty minimal, though. > >I'd forgotten about the Itanium. Both Microsoft and Intel wish the rest >of the world would follow suit :-) I suspect that Intel would have, in retrospect, wished that they had completed P7[*] development rather than cancelling it to team up with HP on Merced. [*] 64-bit RISCish follow-on to the P6. Not EPIC.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-14 14:23 -0700 |
| Message-ID | <61bd06fe-a176-4dfc-b437-9090f469d006@googlegroups.com> |
| In reply to | #112217 |
On Wednesday, June 14, 2017 at 3:39:18 PM UTC-4, Bart wrote: > However, you seem to be under the impression that C imposes some > high-level types on the underlying data. CAlive uses a stricter typing model, one more like C++. The point of my post was that a language and all its nuances basically sits down on top of some data. It processes on that data however it is, and then moves away leaving the data in its altered form. So, in a system like CAlive, there are multiple components sitting down on top of the data, depending on what model is being used and where, but each of them follow a strict set of rules. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-16 13:48 +1200 |
| Message-ID | <eqgrobFe853U3@mid.individual.net> |
| In reply to | #112223 |
On 06/15/17 09:23 AM, Rick C. Hodgin wrote: > On Wednesday, June 14, 2017 at 3:39:18 PM UTC-4, Bart wrote: >> However, you seem to be under the impression that C imposes some >> high-level types on the underlying data. > > CAlive uses a stricter typing model, one more like C++. One that nobody wants? -- Ian
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web