Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #7948 > unrolled thread
| Started by | spud@potato.field |
|---|---|
| First post | 2016-03-01 11:06 +0000 |
| Last post | 2016-03-20 07:12 -0400 |
| Articles | 20 on this page of 186 — 27 participants |
Back to article view | Back to comp.unix.programmer
Odd compiler behaviour? spud@potato.field - 2016-03-01 11:06 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 12:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:48 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 15:46 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 15:08 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:36 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 16:47 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:51 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 17:05 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:00 -0800
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:56 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:42 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:55 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:46 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 20:59 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:09 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 13:03 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:15 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 14:38 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 11:20 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:45 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 16:54 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 13:14 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:10 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 19:26 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:57 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 21:07 +0100
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 15:40 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 21:14 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 21:20 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 22:09 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 23:04 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 17:08 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 22:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 10:39 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 16:19 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 11:56 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 17:21 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 12:42 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:03 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 10:41 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:59 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 11:40 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:05 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 15:32 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:51 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:01 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 21:10 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:41 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:52 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 22:14 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-02 18:54 -0500
Re: Odd compiler behaviour? gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-02 21:30 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:34 -0800
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-05 16:48 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-05 15:29 -0500
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-05 15:41 -0500
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-05 23:19 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-06 12:44 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-06 14:10 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-07 09:53 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 12:59 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 13:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 15:28 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-08 10:42 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-08 17:09 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 20:38 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 22:15 +0000
Re: Odd compiler behaviour? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-03-08 16:21 -0700
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-08 10:47 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 16:04 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 09:40 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 11:31 +0100
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:21 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 12:57 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:32 +0000
Re: Odd compiler behaviour? Robert Wessel <robertwessel2@yahoo.com> - 2016-03-09 11:13 -0600
Re: Odd compiler behaviour? Les Cargill <lcargill99@comcast.com> - 2016-03-09 07:16 -0600
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:19 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:28 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:35 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:08 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:32 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 13:34 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:17 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 16:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:45 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:34 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 15:40 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:57 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 16:07 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 14:12 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 19:51 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 20:08 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:31 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:55 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 17:25 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-11 17:49 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-12 18:11 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 09:43 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 15:57 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 12:16 -0400
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 17:00 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-14 17:14 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:29 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:46 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 18:16 -0400
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 20:45 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 09:25 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 22:36 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 10:23 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-15 10:11 -0400
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 14:33 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 15:41 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-17 18:18 -0400
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-17 23:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 09:44 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 11:31 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 08:32 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 21:46 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 09:25 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 13:22 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 14:07 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 15:59 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 15:12 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 17:27 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:35 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:29 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:23 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 13:14 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 13:38 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 15:20 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:23 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-18 15:58 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 16:20 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-19 02:46 -0400
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-15 15:42 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 21:55 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-15 13:37 +0000
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-31 19:25 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 15:17 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:23 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:30 +0100
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 14:40 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:28 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 10:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 10:29 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 12:50 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 12:21 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 12:22 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-10 13:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 13:55 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-10 08:29 -0800
Re: Odd compiler behaviour? gordonb.uf2r1@burditt.org (Gordon Burditt) - 2016-03-12 03:36 -0600
Re: Odd compiler behaviour? Richard Damon <Richard@Damon-Family.org> - 2016-03-12 10:13 -0500
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-13 23:11 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-13 22:12 +0000
succint expressions (was: Odd compiler behaviour?) Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 11:04 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:39 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 01:00 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:27 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:24 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:10 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:14 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-09 20:18 +0000
Re: Odd compiler behaviour? gordonb.2x965@burditt.org (Gordon Burditt) - 2016-03-14 23:45 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 16:11 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:37 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:34 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 20:05 +0000
[OT] Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-09 15:13 -0500
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:35 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:01 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:09 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-01 14:18 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:53 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 16:44 +0100
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 09:22 -0800
Re: Odd compiler behaviour? David Thompson <dave.thompson2@verizon.net> - 2016-03-20 07:12 -0400
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | spud@potato.field |
|---|---|
| Date | 2016-03-18 09:44 +0000 |
| Message-ID | <ncgili$cit$1@gioia.aioe.org> |
| In reply to | #8180 |
On Thu, 17 Mar 2016 18:18:33 -0400 "James K. Lowden" <jklowden@speakeasy.net> wrote: >On Tue, 15 Mar 2016 15:41:29 +0000 (UTC) >spud@potato.field wrote: >> If by non-experts you mean programmers on the shop floor who use C++ >> to do actual work rather than use it as an interesting academic >> exercise in language design then you're probably right, I doubt the C+ >> + committee listens to any of us. > >Half of all C++ programmers "on the shop floor" have a below-average >understanding of the language. You would agree that below some >percentile of expertise, you wouldn't want their vote. Let's call that >the dividing point between experts and non. I'll accept any proportion >you assert. And I would asset that half of all people who consider themselves language experts are nothing of the sort - they're just arrogant snobs. >Does the ISO process harm the language? Not from what I see. ANSI C >is better than K&R C. ANSI C++ created an arbiter of what is and is >not C++, and eventually cowed Microsoft into correcting the scope of >"I" in "for( int i=-0;...)" I'll give you ANSI-C, but in the case of C they knew when to leave well alone and only added small incremental actually useful updates. They didn't add in huge amounts of useless crap on every revision. eg it would have been perfectly possibly to add lambda functions to C. They didn't, thank god. >"Now, by popular demand" is a terrible model. It's plausible that's >what killed Perl. It's definitely what made such an ugly mess of SQL. Well Perl isn't dead yet, but what did for it and gave Python the edge was Larry et al not knowing when to leave well alone. Sound familiar? Though Python 3 hasn't exactly been a resounding success either TBH. >Users -- the vast majorty, including their management -- didn't >appreciate (still don't) the power of the underlying theory. What they >wanted was speed and convenience. And vendors delivered! Over the Say it ain't so! Users want a language that makes their job easier?? No! I'll tell you what you get when you design a language according to what academics think is a good idea - you get functional programming. A nice theoretical idea that looks good in a whitepaper but inefficient and awkward when dealing with real problems on real processors. How many job ads for Haskell or F# do you ever see out side of Academia? Arguably the only really well used functional language is Erlang but even that is still pretty much confined to telecoms kit. >decades SQL has changed quite a bit, but *never* in the direction of >addressing acknowledged, well understood flaws in its definition of the >relational model. The relational model is not always a perfect fit in the real world. Hence you have non relational extensions to SQL. Also it explains the rise of no-sql databases such as Mongo. >There is a place in language development for academics and people with >access to a wide variety of code bases. The academics provide the >theory and hopefully prevent ambiguous or redundant constructions. And the users tell the academics whats required on the shop floor. Programming languages are a means to an end, not an end in themselves. >Observation of code bases minimized incompatible changes. C++ has >demonstrably benefitted from such people on the committee. Hmm. >> Reflection in a compiled language requires a lot of runtime baggage >> to make it work. No thanks. > >It all depends what you mean. What *I* mean is to include in the >compiled image -- as static data in a new namespace -- structures that >describe the compiled program. I want all the data currently supplied Thats just sophisticated RTTI. True reflection allows modification of code at runtime. Not something thats easy to do with compiled code short of putting a compiler engine in the runtime. >> Concurrency should be the responsibility of the OS, not the language. > >No. The OS knows nothing of types. Everything is just a bag of >bytes. There's no way to say a pipe or a file only takes objects of >type X, no support from the compiler in filling or emptying the pipe. If you want that sort of nonsense use Java and its serialisation systems. >The compiler cannot opt to support the same logical separation more >efficiently with threads. How do you suggest it does concurrency if it doesn't use OS threads? Roll its own multithreading like java? Give me a break. >Compilers prevent errors. If you fix the definitions of "language" and >"OS" in 1975, how do you ever progress? Because they haven't changed since 1975. An OS is still an OS and a compiler still creates binaries to run on that OS. Pretending the 2 overlap in some way is specious - they don't. At all. Again - if you want some sort of VM functionality where the language and the VM do overlap by design then use a VM language. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-03-29 11:31 +1300 |
| Message-ID | <dltpmgFhjrsU5@mid.individual.net> |
| In reply to | #8184 |
On 03/18/16 22:44, spud@potato.field wrote: > On Thu, 17 Mar 2016 18:18:33 -0400 > "James K. Lowden" <jklowden@speakeasy.net> wrote: >> On Tue, 15 Mar 2016 15:41:29 +0000 (UTC) >> spud@potato.field wrote: > >> Does the ISO process harm the language? Not from what I see. ANSI C >> is better than K&R C. ANSI C++ created an arbiter of what is and is >> not C++, and eventually cowed Microsoft into correcting the scope of >> "I" in "for( int i=-0;...)" > > I'll give you ANSI-C, but in the case of C they knew when to leave well alone > and only added small incremental actually useful updates. They didn't add in > huge amounts of useless crap on every revision. eg it would have been perfectly > possibly to add lambda functions to C. They didn't, thank god. I'll give you <tgmath.h> :) >>> Concurrency should be the responsibility of the OS, not the language. >> >> No. The OS knows nothing of types. Everything is just a bag of >> bytes. There's no way to say a pipe or a file only takes objects of >> type X, no support from the compiler in filling or emptying the pipe. > > If you want that sort of nonsense use Java and its serialisation systems. > >> The compiler cannot opt to support the same logical separation more >> efficiently with threads. > > How do you suggest it does concurrency if it doesn't use OS threads? Roll its > own multithreading like java? Give me a break. The compiler not only uses OS threads, but it needs to be aware of them in order to generate the best code. Probably the the addition of atomic operations to both C and C++ was even more useful. Adding threads and atomics to the language makes the job of the humble cross-platform developer that be easier. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-29 08:32 +0000 |
| Message-ID | <nddeio$1vif$1@gioia.aioe.org> |
| In reply to | #8253 |
On Tue, 29 Mar 2016 11:31:44 +1300 Ian Collins <ian-news@hotmail.com> wrote: >On 03/18/16 22:44, spud@potato.field wrote: >> How do you suggest it does concurrency if it doesn't use OS threads? Roll its >> own multithreading like java? Give me a break. > >The compiler not only uses OS threads, but it needs to be aware of them >in order to generate the best code. Probably the the addition of atomic If its not aware of them it won't be generating any of its own threading code. >operations to both C and C++ was even more useful. Adding threads and They can add atomics to the language - but if its not supported by the OS then they won't work. >atomics to the language makes the job of the humble cross-platform >developer that be easier. Any code sufficiently complex to use threading will almost certainly be using other OS specific functionality which the compiler doesn't support other than via libraries, plus there will invariably be platform specific threading options that a generic model can't by definition include so I really don't see the point. Also why did they stop at multithreading in the language? What about the far more useful multiprocess? Surely nothing to do with Windows still not being able to support it properly... -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-03-29 21:46 +1300 |
| Message-ID | <dlutnnFhjrsU8@mid.individual.net> |
| In reply to | #8254 |
On 03/29/16 21:32, spud@potato.field wrote: > On Tue, 29 Mar 2016 11:31:44 +1300 > Ian Collins <ian-news@hotmail.com> wrote: >> On 03/18/16 22:44, spud@potato.field wrote: >>> How do you suggest it does concurrency if it doesn't use OS threads? Roll its >>> own multithreading like java? Give me a break. >> >> The compiler not only uses OS threads, but it needs to be aware of them >> in order to generate the best code. Probably the the addition of atomic > > If its not aware of them it won't be generating any of its own threading code. Isn't that what I said? >> operations to both C and C++ was even more useful. Adding threads and > > They can add atomics to the language - but if its not supported by the OS > then they won't work. Have you seen the name of this group? >> atomics to the language makes the job of the humble cross-platform >> developer that be easier. > > Any code sufficiently complex to use threading will almost certainly be using > other OS specific functionality which the compiler doesn't support other than > via libraries, plus there will invariably be platform specific threading > options that a generic model can't by definition include so I really don't see > the point. Nope. I have code that runs quite happily using the standard library on naked ARM and hosted Unix and windoze. > Also why did they stop at multithreading in the language? What about the far > more useful multiprocess? Surely nothing to do with Windows still not being > able to support it properly... No demand? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-29 09:25 +0000 |
| Message-ID | <nddhlq$539$1@gioia.aioe.org> |
| In reply to | #8255 |
On Tue, 29 Mar 2016 21:46:47 +1300 Ian Collins <ian-news@hotmail.com> wrote: >On 03/29/16 21:32, spud@potato.field wrote: >> On Tue, 29 Mar 2016 11:31:44 +1300 >> Ian Collins <ian-news@hotmail.com> wrote: >>> On 03/18/16 22:44, spud@potato.field wrote: >>>> How do you suggest it does concurrency if it doesn't use OS threads? Roll >its >>>> own multithreading like java? Give me a break. >>> >>> The compiler not only uses OS threads, but it needs to be aware of them >>> in order to generate the best code. Probably the the addition of atomic >> >> If its not aware of them it won't be generating any of its own threading >code. > >Isn't that what I said? You said in order to generate the best code. I said they need to know about them to generate ANY code. >>> operations to both C and C++ was even more useful. Adding threads and >> >> They can add atomics to the language - but if its not supported by the OS >> then they won't work. > >Have you seen the name of this group? We're talking about cross platform functionality. Good luck getting threading and atomics to work on a lot of microcontrollers. >> Any code sufficiently complex to use threading will almost certainly be using >> other OS specific functionality which the compiler doesn't support other than >> via libraries, plus there will invariably be platform specific threading >> options that a generic model can't by definition include so I really don't >see >> the point. > >Nope. I have code that runs quite happily using the standard library on >naked ARM and hosted Unix and windoze. What nope? >> Also why did they stop at multithreading in the language? What about the far >> more useful multiprocess? Surely nothing to do with Windows still not being >> able to support it properly... > >No demand? Where was the demand for threading to be bundled in C++? It seems to me a lot of the recent features adding to C++ are down purely to confirmation bias on the part of the committee responsible and have little to do with what users actually want or need. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-29 13:22 +0000 |
| Message-ID | <kkvKy.64376$bB1.22081@fx30.iad> |
| In reply to | #8254 |
spud@potato.field writes: >On Tue, 29 Mar 2016 11:31:44 +1300 >Ian Collins <ian-news@hotmail.com> wrote: >>On 03/18/16 22:44, spud@potato.field wrote: >>> How do you suggest it does concurrency if it doesn't use OS threads? Roll its >>> own multithreading like java? Give me a break. >> >>The compiler not only uses OS threads, but it needs to be aware of them >>in order to generate the best code. Probably the the addition of atomic > >If its not aware of them it won't be generating any of its own threading code. > >>operations to both C and C++ was even more useful. Adding threads and > >They can add atomics to the language - but if its not supported by the OS >then they won't work. The addition of atomics (and memory models) to the languages is to support the various hardware implementations available in a hardware-independent fashion. The atomics are simply generated instructions, no operating system support is necessary. On X86, you've the CMPXCHG and LOCK-prefix instructions for atomicity, while on ARM64, you've the load/store exclusive, compare and swap and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or with memory); which again, require no support from the OS. New language features such as threads do require OS support, but pretty much every modern OS supports some form of threads (e.g. pthreads), and using common language facilities for threads eliminates another point of source code divergence between operating systems. The one, single, useful new feature in C++11 is threads and associated memory model. Everything else is useless syntactic suger (e.g. lambdas).
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-29 14:07 +0000 |
| Message-ID | <nde27h$1367$1@gioia.aioe.org> |
| In reply to | #8259 |
On Tue, 29 Mar 2016 13:22:24 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >spud@potato.field writes: >>They can add atomics to the language - but if its not supported by the OS >>then they won't work. > > The addition of atomics (and memory models) to the languages is to >support the various hardware implementations available in a >hardware-independent >fashion. The atomics are simply generated instructions, no operating system >support is necessary. On X86, you've the CMPXCHG and LOCK-prefix >instructions >for atomicity, while on ARM64, you've the load/store exclusive, compare and >swap >and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or >with memory); >which again, require no support from the OS. I was thinking more of atomic test and set for thread mutexes. You can't implement that functionality with a single CPU instruction since it involves data shared between threads that may be running on multiple cores. >model. Everything else is useless syntactic suger (e.g. lambdas). Agreed. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2016-03-29 15:59 +0100 |
| Message-ID | <87a8lhib40.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #8260 |
spud@potato.field writes:
> On Tue, 29 Mar 2016 13:22:24 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>spud@potato.field writes:
>>>They can add atomics to the language - but if its not supported by the OS
>>>then they won't work.
>>
>> The addition of atomics (and memory models) to the languages is to
>>support the various hardware implementations available in a
>>hardware-independent
>>fashion. The atomics are simply generated instructions, no operating system
>>support is necessary. On X86, you've the CMPXCHG and LOCK-prefix
>>instructions
>>for atomicity, while on ARM64, you've the load/store exclusive, compare and
>>swap
>>and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or
>>with memory);
>>which again, require no support from the OS.
>
> I was thinking more of atomic test and set for thread mutexes. You can't
> implement that functionality with a single CPU instruction since it involves
> data shared between threads that may be running on multiple cores.
[rw@doppelsaurus]/tmp#cat c.c
static int v = 1;
int main(void)
{
int vv;
vv = __sync_lock_test_and_set(&v, 2);
return 0;
}
[rw@doppelsaurus]/tmp#gcc -S -O2 -o - c.c
.file "c.c"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
movl $2, %eax
xchgl v(%rip), %eax
xorl %eax, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.data
.align 4
.type v, @object
.size v, 4
v:
.long 1
.ident "GCC: (Debian 4.7.2-5) 4.7.2"
.section .note.GNU-stack,"",@progbits
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-29 15:12 +0000 |
| Message-ID | <nde611$1adl$1@gioia.aioe.org> |
| In reply to | #8261 |
On Tue, 29 Mar 2016 15:59:11 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>spud@potato.field writes:
>> On Tue, 29 Mar 2016 13:22:24 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>spud@potato.field writes:
>>>>They can add atomics to the language - but if its not supported by the OS
>>>>then they won't work.
>>>
>>> The addition of atomics (and memory models) to the languages is to
>>>support the various hardware implementations available in a
>>>hardware-independent
>>>fashion. The atomics are simply generated instructions, no operating system
>>>support is necessary. On X86, you've the CMPXCHG and LOCK-prefix
>>>instructions
>>>for atomicity, while on ARM64, you've the load/store exclusive, compare and
>>>swap
>>>and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or
>>>with memory);
>>>which again, require no support from the OS.
>>
>> I was thinking more of atomic test and set for thread mutexes. You can't
>> implement that functionality with a single CPU instruction since it involves
>> data shared between threads that may be running on multiple cores.
>
>[rw@doppelsaurus]/tmp#cat c.c
>static int v = 1;
>
>int main(void)
>{
> int vv;
>
> vv = __sync_lock_test_and_set(&v, 2);
Thats not a thread mutex is it.
> xchgl v(%rip), %eax
Thats fine for one CPU. But what happens if another CPU/core comes along and
does an operation at that memory address. Whose cache gets flushed to
memory first? You want to bet on it being CPU 1?
Proper atomic operations need to lock the memory page/word - i have no idea if
that x86 instruction does so but I wouldn't lay money on it.
--
Spud
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2016-03-29 17:27 +0100 |
| Message-ID | <871t6ti70o.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #8262 |
spud@potato.field writes:
> On Tue, 29 Mar 2016 15:59:11 +0100
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>spud@potato.field writes:
[...]
>>> I was thinking more of atomic test and set for thread mutexes. You can't
>>> implement that functionality with a single CPU instruction since it involves
>>> data shared between threads that may be running on multiple cores.
>>
>>[rw@doppelsaurus]/tmp#cat c.c
>>static int v = 1;
>>
>>int main(void)
>>{
>> int vv;
>>
>> vv = __sync_lock_test_and_set(&v, 2);
>
> Thats not a thread mutex is it.
That's an (Intel-defined) gcc builtin doing an atomic test-and-set
>> xchgl v(%rip), %eax
>
> Thats fine for one CPU. But what happens if another CPU/core comes along and
> does an operation at that memory address.
and that's the single x86 machine instruction used to implement it.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-30 08:35 +0000 |
| Message-ID | <ndg35c$fro$1@gioia.aioe.org> |
| In reply to | #8266 |
On Tue, 29 Mar 2016 17:27:35 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>spud@potato.field writes:
>> On Tue, 29 Mar 2016 15:59:11 +0100
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>spud@potato.field writes:
>
>[...]
>
>>>> I was thinking more of atomic test and set for thread mutexes. You can't
>>>> implement that functionality with a single CPU instruction since it
>involves
>>>> data shared between threads that may be running on multiple cores.
>>>
>>>[rw@doppelsaurus]/tmp#cat c.c
>>>static int v = 1;
>>>
>>>int main(void)
>>>{
>>> int vv;
>>>
>>> vv = __sync_lock_test_and_set(&v, 2);
>>
>> Thats not a thread mutex is it.
>
>That's an (Intel-defined) gcc builtin doing an atomic test-and-set
Though the gcc documentation suggests not to rely on that:
https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
"Many targets have only minimal support for such locks, and do not support a
full exchange operation. In this case, a target may support reduced
functionality here by which the only valid value to store is the immediate
constant 1"
--
Spud
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-29 16:29 +0000 |
| Message-ID | <b4yKy.84823$LP.9185@fx16.iad> |
| In reply to | #8262 |
spud@potato.field writes:
>On Tue, 29 Mar 2016 15:59:11 +0100
>Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>spud@potato.field writes:
>>> On Tue, 29 Mar 2016 13:22:24 GMT
>>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>spud@potato.field writes:
>>>>>They can add atomics to the language - but if its not supported by the OS
>>>>>then they won't work.
>>>>
>>>> The addition of atomics (and memory models) to the languages is to
>>>>support the various hardware implementations available in a
>>>>hardware-independent
>>>>fashion. The atomics are simply generated instructions, no operating system
>>>>support is necessary. On X86, you've the CMPXCHG and LOCK-prefix
>>>>instructions
>>>>for atomicity, while on ARM64, you've the load/store exclusive, compare and
>>>>swap
>>>>and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or
>>>>with memory);
>>>>which again, require no support from the OS.
>>>
>>> I was thinking more of atomic test and set for thread mutexes. You can't
>>> implement that functionality with a single CPU instruction since it involves
>>> data shared between threads that may be running on multiple cores.
>>
>>[rw@doppelsaurus]/tmp#cat c.c
>>static int v = 1;
>>
>>int main(void)
>>{
>> int vv;
>>
>> vv = __sync_lock_test_and_set(&v, 2);
>
>Thats not a thread mutex is it.
>
>> xchgl v(%rip), %eax
>
>Thats fine for one CPU. But what happens if another CPU/core comes along and
>does an operation at that memory address. Whose cache gets flushed to
>memory first? You want to bet on it being CPU 1?
>
>Proper atomic operations need to lock the memory page/word - i have no idea if
>that x86 instruction does so but I wouldn't lay money on it.
>
You'd lose that bet.
XCHGL will acquire the cache line containing the 32-bit
value being exchanged in a mode that makes the cache line
exclusive to the requesting core. No other core can
access that 64-byte line until the cache line is transferred
from the owning core to the new requesting core. There's your
serialization. For non-cachable memory, the system-wide
bus-lock will be acquired (as it would be if the 32-bit data
item spanned multiple cache lines - something that programmers/compilers
have been trained to avoid since caches became common). One
tends to avoid the bus lock as it serializes the entire system
and doesn't scale well to higher core counts.
The Intel, AMD and ARM architecture documents go into great detail
on how all this works.
/**
* Try to acquire the lock, without spinning. If successful, return
* true.
*/
inline int
c_spinlock::trylock(void)
{
int previous;
__asm__ __volatile__ ("xchgl %0,%1": "=q" (previous), "=m" (lockval)
: "0" (0) : "memory");
return (previous > 0);
}
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-30 08:23 +0000 |
| Message-ID | <ndg2df$ekq$1@gioia.aioe.org> |
| In reply to | #8267 |
On Tue, 29 Mar 2016 16:29:59 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >spud@potato.field writes: >>Thats fine for one CPU. But what happens if another CPU/core comes along and >>does an operation at that memory address. Whose cache gets flushed to >>memory first? You want to bet on it being CPU 1? >> >>Proper atomic operations need to lock the memory page/word - i have no idea >if >>that x86 instruction does so but I wouldn't lay money on it. >> > >You'd lose that bet. > >XCHGL will acquire the cache line containing the 32-bit >value being exchanged in a mode that makes the cache line >exclusive to the requesting core. No other core can >access that 64-byte line until the cache line is transferred >from the owning core to the new requesting core. There's your >serialization. For non-cachable memory, the system-wide >bus-lock will be acquired (as it would be if the 32-bit data >item spanned multiple cache lines - something that programmers/compilers >have been trained to avoid since caches became common). One >tends to avoid the bus lock as it serializes the entire system >and doesn't scale well to higher core counts. > >The Intel, AMD and ARM architecture documents go into great detail >on how all this works. Fair enough. One is never too old to learn something new. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-30 13:14 +0000 |
| Message-ID | <ijQKy.110871$X_.33591@fx04.iad> |
| In reply to | #8271 |
spud@potato.field writes:
>On Tue, 29 Mar 2016 16:29:59 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>spud@potato.field writes:
>>>Thats fine for one CPU. But what happens if another CPU/core comes along and
>>>does an operation at that memory address. Whose cache gets flushed to
>>>memory first? You want to bet on it being CPU 1?
>>>
>>>Proper atomic operations need to lock the memory page/word - i have no idea
>>if
>>>that x86 instruction does so but I wouldn't lay money on it.
>>>
>>
>>You'd lose that bet.
>>
>>XCHGL will acquire the cache line containing the 32-bit
>>value being exchanged in a mode that makes the cache line
>>exclusive to the requesting core. No other core can
>>access that 64-byte line until the cache line is transferred
>>from the owning core to the new requesting core. There's your
>>serialization. For non-cachable memory, the system-wide
>>bus-lock will be acquired (as it would be if the 32-bit data
>>item spanned multiple cache lines - something that programmers/compilers
>>have been trained to avoid since caches became common). One
>>tends to avoid the bus lock as it serializes the entire system
>>and doesn't scale well to higher core counts.
>>
>>The Intel, AMD and ARM architecture documents go into great detail
>>on how all this works.
>
>Fair enough. One is never too old to learn something new.
>
Back in the day, working on Burroughs mainframe operating systems,
we built our first SMP machine. We needed a mutual exclusion mechanism,
so we built the lock instruction directly into the instruction set.
Internally, the processor logic used an atomic test&set operation to acquire
exclusive access to the data structure describing the lock (20 nibbles)
and stored the active task number as the owner, verified that the
lock level number (range 0 to 9999) was higher than any prior locks
acquired[*], and marked the lock as owned. When another processor attempted
to acquire the lock and found that it was already locked, the processor
would interrupt to the microkernel to park the current task and schedule
another on that processor.
http://vseries.lurndal.org/doku.php?id=instructions:lok
[*] This prevented deadlocks. If nested locks
weren't released in the reverse order they were acquired, a fault
would be raised, and they could only be acquired in increasing
numeric order.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-30 13:38 +0000 |
| Message-ID | <ndgksh$1ech$1@gioia.aioe.org> |
| In reply to | #8275 |
On Wed, 30 Mar 2016 13:14:54 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >lock level number (range 0 to 9999) was higher than any prior locks Was 9999 an arbitrary "seems large enough" value, or was it stored as 2 byte BCD? -- Spud
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-30 15:20 +0000 |
| Message-ID | <59SKy.73545$6%.1982@fx02.iad> |
| In reply to | #8277 |
spud@potato.field writes: >On Wed, 30 Mar 2016 13:14:54 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >>lock level number (range 0 to 9999) was higher than any prior locks > >Was 9999 an arbitrary "seems large enough" value, or was it stored as 2 byte >BCD? > The architecture addressed to the digit (nibble). It requires four digits (see the data structure diagram on the link provided in the parent post). We figured at the time that 10000 nested locks were more than plenty :-) (although choosing the right canonical lock number was fraught :-()
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-29 16:23 +0000 |
| Message-ID | <%ZxKy.84822$LP.68158@fx16.iad> |
| In reply to | #8260 |
spud@potato.field writes:
>On Tue, 29 Mar 2016 13:22:24 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>spud@potato.field writes:
>>>They can add atomics to the language - but if its not supported by the OS
>>>then they won't work.
>>
>> The addition of atomics (and memory models) to the languages is to
>>support the various hardware implementations available in a
>>hardware-independent
>>fashion. The atomics are simply generated instructions, no operating system
>>support is necessary. On X86, you've the CMPXCHG and LOCK-prefix
>>instructions
>>for atomicity, while on ARM64, you've the load/store exclusive, compare and
>>swap
>>and various atomic arithmetic operations (e.g. LDEOR - atomic exclusive or
>>with memory);
>>which again, require no support from the OS.
>
>I was thinking more of atomic test and set for thread mutexes. You can't
>implement that functionality with a single CPU instruction since it involves
>data shared between threads that may be running on multiple cores.
Sure you can (this was used on a 192-core system):
/**
* Obtain the lock, spinning if necessary. See class documentation for
* algorithm details.
*/
inline void
c_spinlock::lock(void)
{
__asm__ __volatile__ (
"\n1:\t"
"lock; decl %0\n\t"
"jz 3f\n"
"2:\n\t"
"rep; nop\n\t"
"cmpl $0, %0\n\t"
"jle 2b\n\t"
"jmp 1b\n\t"
"3:\n\t": "=m" (lockval) : : "memory");
}
/**
* Release the lock. See class documentation for algorithm details.
*/
inline void
c_spinlock::unlock(void)
{
__asm__ __volatile__ ("movl $1, %0": "=m" (lockval): : "memory");
}
The only time you need the OS to be involved is when you want
the os to reschedule a different process/thread on the core
rather than busy-waiting.
(now, GCC has built-in intrinsics for most of this).
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2016-03-18 15:58 +0000 |
| Message-ID | <87mvpveq27.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #8180 |
"James K. Lowden" <jklowden@speakeasy.net> writes: [...] > "Now, by popular demand" is a terrible model. It's plausible that's > what killed Perl. It's definitely what made such an ugly mess of SQL. > Users -- the vast majorty, including their management -- didn't > appreciate (still don't) the power of the underlying theory. The (comic) tragedy of SQL is that it was suposed to enable people to do database queries without having to learn an imperative programming language first. But people who aren't programmers don't want to learn SQL. They want their application programmers to deal with this. And their application programmers already know how to program in an imperative programming language and don't want to learn SQL, either.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-18 16:20 +0000 |
| Message-ID | <nch9t8$1njd$1@gioia.aioe.org> |
| In reply to | #8198 |
On Fri, 18 Mar 2016 15:58:08 +0000 Rainer Weikusat <rweikusat@talktalk.net> wrote: >"James K. Lowden" <jklowden@speakeasy.net> writes: > >[...] > >> "Now, by popular demand" is a terrible model. It's plausible that's >> what killed Perl. It's definitely what made such an ugly mess of SQL. >> Users -- the vast majorty, including their management -- didn't >> appreciate (still don't) the power of the underlying theory. > >The (comic) tragedy of SQL is that it was suposed to enable people to do >database queries without having to learn an imperative programming >language first. But people who aren't programmers don't want to learn >SQL. They want their application programmers to deal with this. And >their application programmers already know how to program in an >imperative programming language and don't want to learn SQL, either. Another problem of course, is that a sufficiently complex SQL query is actually sometimes harder to understand than imperative code that does the same thing especially when nested correlated subqueries come into the picture. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | "James K. Lowden" <jklowden@speakeasy.net> |
|---|---|
| Date | 2016-03-19 02:46 -0400 |
| Message-ID | <20160319024647.c4297b44f53d3cab28f02f02@speakeasy.net> |
| In reply to | #8199 |
On Fri, 18 Mar 2016 16:20:57 +0000 (UTC) spud@potato.field wrote: > On Fri, 18 Mar 2016 15:58:08 +0000 > Rainer Weikusat <rweikusat@talktalk.net> wrote: > >"James K. Lowden" <jklowden@speakeasy.net> writes: > > > >[...] > > > >> "Now, by popular demand" is a terrible model. It's plausible > >> that's what killed Perl. It's definitely what made such an ugly > >> mess of SQL. Users -- the vast majorty, including their management > >> -- didn't appreciate (still don't) the power of the underlying > >> theory. > > > >The (comic) tragedy of SQL is that it was suposed to enable people > >to do database queries without having to learn an imperative > >programming language first. But people who aren't programmers don't > >want to learn SQL. They want their application programmers to deal > >with this. And their application programmers already know how to > >program in an imperative programming language and don't want to > >learn SQL, either. Only too true! SQL was invented in the 80s for the "end user", hence the "Q". If you were designing a set-theoretic lanaguage for the professional programmer, one would like to think the result would be very different. Or not. A great many programmers have no formal training. A great many SQL programmers no nothing of the relational model. Thus the continued popularity of ORM schlock instead of education and training in higher-order operations. > Another problem of course, is that a sufficiently complex SQL query > is actually sometimes harder to understand than imperative code I've written a lot of SQL code in my time, and while I can't say that never happens, I know it's exceedingly rare. Especially if the "sufficiently complex SQL" is written as simply (i.e., in as few words) as possible. In an imperative language, every join requires a loop. Every correlated subquery (there exists) requires a loop. Every IN and EXISTS requires a loop. The machinery to drive the imperative algorithm obscures the set-theory logic, and is error-prone besides. --jkl
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web