brnstnd@stealth.acf.nyu.edu (02/08/90)
The default case should be the safe one. ---Dan
barmar@think.com (Barry Margolin) (02/08/90)
In article <1117.18:37:35@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >The default case should be the safe one. No, the default case should be the common one. Most programs have *no* volatile variables. Programmers would get pretty tired of writing "nonvolatile" before every variable declaration. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
henry@utzoo.uucp (Henry Spencer) (02/09/90)
In article <1117.18:37:35@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >The default case should be the safe one. No, the default case should be the one people usually want, which is "no funny stuff going on, feel free to optimize". This is, in any case, what most C compilers have done by default all along (with the result that elaborate trickery was sometimes needed to get the effect of volatile), so there is no sudden drop in safety. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
woody@rpp386.cactus.org (Woodrow Baker) (02/11/90)
In article <1990Feb8.162440.22318@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <1117.18:37:35@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: > most C compilers have done by default all along (with the result that > elaborate trickery was sometimes needed to get the effect of volatile), > so there is no sudden drop in safety. I wish that there had been more notice, or information as to when the standards meetings were held, or that they had gotten a wider input. They virtually ignored the needs of control programmers. Features that were not adopted, for lack of support, and /or were not brought up: Flexible way to declare a function as an interrupt handler. I like Turbo 'C's modifier of interrupt. It simply brackets the entire function with a push all registers, and restore all registers. The definition of it would be: saves the entire working register set of the machine and restores it on exit. QUADS. I.E. double longs. FIXED i.e. fixed point math. This type would deal with chars,ints, longs and quads. There would be an assumed binary point in the middle of the data. for chars, between the left and right nibbles, for ints, between teh smallest unit of an int. For longs, between the halves, i.e. for 16 bit intergers, between the 2 bytes etc. The operators, + - / * % should work on these, and conversions to unsigned types of the same size, should have no modifications to the values. These would aid control programming a lot. We use 'C' for several projects, including embedded 8051 micro processors. Cheers Woody > -- > SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology > wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/13/90)
In article <17910@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >I wish that there had been more notice, or information as to when the >standards meetings were held, or that they had gotten a wider input. It was fairly widely publicized in the C community at the time, actually. >They virtually ignored the needs of control programmers. Looking at the list of X3J11 members, I really doubt this -- there is no shortage of people there from companies with very heavy involvement in such things. >Flexible way to declare a function as an interrupt handler. >I like Turbo 'C's modifier of interrupt. Unfortunately very machine-specific. No, not all machines have interrupts resembling those of the 8086. This is also an area where a little bit of assembly-language glue -- often necessary anyway -- goes a very long way to solving the problem. >It simply brackets the entire function with a push all registers, and >restore all registers. The definition of it would be: saves the >entire working register set of the machine and restores it on exit. This is vast overkill for interrupts on, say, the AMD 29000 -- a machine being sold primarily to the high-end control market, and one that is noted for blazing-fast interrupt handling. Actually, many modern processor architectures (the 8086 and descendants do not qualify!) have special provisions for very-low-latency interrupts that would be ill-served by such a feature. >QUADS. I.E. double longs. The "common extensions" discussion in the appendix mentions "long long int" among other things. I think the major problem here was simply that there was little experience with it. Pity. >FIXED i.e. fixed point math. This type would deal with chars,ints, longs >and quads. There would be an assumed binary point in the middle of the >data... But *I* want the assumed binary point three bits from the right! :-) This whole area is a massive swamp of conversion rules, overflow handling, etc. I doubt that anyone has ever added this to C, and I think there is good reason to fear the consequences. Despite some of the uninformed flaming, very little of what's in ANSI C is actually X3J11 inventions: almost all of it has actually been tried, and proven workable, in some C compiler somewhere. This is important. The few things that *were* X3J11 inventions are among the worst botches in the standard. -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
raymond@twinkies.berkeley.edu (Raymond Chen) (02/13/90)
In article <17910@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >FIXED i.e. fixed point math. This type would deal with chars,ints, longs >and quads. There would be an assumed binary point in the middle of the >data. ... Can you say PL/I? I knew you could... raymond@math.berkeley.edu mathematician by training, hacker by choice
exspes@bath.ac.uk (P E Smee) (02/13/90)
In article <1990Feb12.182343.14269@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <17910@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >>FIXED i.e. fixed point math. This type would deal with chars,ints, longs >>and quads. There would be an assumed binary point in the middle of the >>data... > >But *I* want the assumed binary point three bits from the right! :-) This >whole area is a massive swamp of conversion rules, overflow handling, etc. PL/1 offered that. In years of PL/1 programming, I believe I only ever saw two or three programs (by anyone) that used it. A declaration such as 'fixed bin (31, 6)' meant you wanted a fixed-point number 31 bits long, with the assumed binary point 6 bits from the right (or was it the left?). It had the advantage over C that you didn't have the long/int/short/char porting problems -- you said how many BITS you needed for the value, and let the compiler worry about how many of what sort of storage units that implied. (The compiler could pad for alignment -- unless you forbade it.) It had the disadvantage that the conversions (particularly when operating on operands of different types) were so baroque that it was actually usually easier to simply declare everything as 'fixed bin (n,0)' (effectively, int/long/short) and to keep track of any assumed binary point yourself. Was a rich source of difficulty in the few places I saw it used. -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (02/13/90)
> The few things that *were* X3J11 inventions > are among the worst botches in the standard. I couldn't agree more. ANSI C should codify existing practice, rather than introduce a new language with subtly different semantics than K&R. And they should not have mucked with so many include files. Thank God they backed down on noalias! But why did they keep trigraphs? ----- jeffa
meissner@osf.org (Michael Meissner) (02/14/90)
In article <680016@hpmwjaa.HP.COM> jeffa@hpmwtd.HP.COM (Jeff Aguilera) writes: | > The few things that *were* X3J11 inventions | > are among the worst botches in the standard. | | I couldn't agree more. ANSI C should codify existing practice, rather than | introduce a new language with subtly different semantics than K&R. But K&R was already out of sync with current practice: 1) K&R demands that globals obey strict REF/DEF semantics (you can have only 1 definition of a global variable, everything else must be an 'extern' reference); 2) K&R demands that the preprocessor not substitute macro arguments into string literals and character constants; 3) The grammar in appendix A of K&R-I is incorrect with regard to functions returning pointers to functions, and where the arguments go; 4) K&R does not have the extensions (structure copy/args/return, possibly enumerations) that found their way into the V7 compilers, and were considered existing practice by the time ANSI started; 5) The Richie PDP-11 compiler and the Johnson PCC (portable C compiler) have different semantics with regard to incomplete nesting of braces in initializers; (and so on) I would also imagine, that more people use Turbo C nowadays than ever used PCC, so what is the current existing practice if it's a choice between these two? | And they should not have mucked with so many include files. | | Thank God they backed down on noalias! But why did they keep trigraphs? Because there was not enough votes. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (02/16/90)
> I would also imagine, that more people use Turbo C nowadays than ever > used PCC, so what is the current existing practice if it's a choice > between these two? Gee. I don't see cdecl, pascal, near, far, interrupt, ... in the standard. Methinks existing practice is the intersection of all portable code, not one vendor's installed base. Is that ambiguous enough :-? ----- jeffa
woody@rpp386.cactus.org (Woodrow Baker) (02/16/90)
In article <1990Feb13.114041.4178@bath.ac.uk>, exspes@bath.ac.uk (P E Smee) writes: > In article <1990Feb12.182343.14269@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >In article <17910@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >>FIXED i.e. fixed point math. This type would deal with chars,ints, longs > >>and quads. There would be an assumed binary point in the middle of the > >>data... > > > >But *I* want the assumed binary point three bits from the right! :-) This > >whole area is a massive swamp of conversion rules, overflow handling, etc. > > PL/1 offered that. In years of PL/1 programming, I believe I only ever > saw two or three programs (by anyone) that used it. A declaration such > as 'fixed bin (31, 6)' meant you wanted a fixed-point number 31 bits > long, with the assumed binary point 6 bits from the right (or was it > the left?). It had the advantage over C that you didn't have the > long/int/short/char porting problems -- you said how many BITS you > needed for the value, and let the compiler worry about how many of what > sort of storage units that implied. (The compiler could pad for > alignment -- unless you forbade it.) > > It had the disadvantage that the conversions (particularly when > operating on operands of different types) were so baroque that it was > actually usually easier to simply declare everything as 'fixed bin > (n,0)' (effectively, int/long/short) and to keep track of any assumed hmmm. Where it would be useful, would be in scaling operations. Scaling things like thermocouple readings, and so forth, using 'C', you have the overhead of a floating point package. IF you are developing code to say, fit in a 4k 8051, you can't afford the codespace for a FP, but fixed integer would substitue nicely. People, missed my point, that fixed point does not require conversions. A fixed int and an int are the same thing. i.e., they should substitue for each other. It is merely where you have the binary point. Conversion to and from float, fixed, and int are not a problem. fixed to float is real easy, float to fixed is also easy. It is up to the programmer to be sure that the floating number is within range of the fixed point number that you are converting it to. conversion to and from integer, merely is moving the bit pattern, It would be up to the programmer to truncate the fraction portion first, if he so desired. Anything that needs fast, non- integer math would benefit. Postscript interpreters, batch control and weighting systems, etc. Tom Plum, told me that the QUAD idea was mentioned, but died "because it had no champion". Fixed wasn't even thought of. It seems that the average joe programmer can't influence things like standards committees easily. How do you manage to get onto a commitee like that? How do you get to attend the meetings and present ideas? I never found any addresses, schedules, contact points, meeting places or dates published in normal industry traderags, or special magazines, like DR. Dobbs, or PC week etc.... Perhaps PC week would not be a good place, but it is rather widely followed.... Cheers Woody
henry@utzoo.uucp (Henry Spencer) (02/17/90)
In article <17950@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >... It seems that the >average joe programmer can't influence things like standards committees >easily. How do you manage to get onto a commitee like that? Basically, you pay a modest fee, and show up for the meetings. It's not difficult; if you look at the list of committee members in the drafts (or, I assume, the final standard), you'll see a number who have no institutional affiliation listed. Having your employer's support helps when it comes to the costs of attending meetings, but attendance in fact isn't required, although it helps if you want to really have a voice in things. You can do it by mail. Actually, the hardest part of being a standards-committee member is all the massive piles of paper you have to wade through to do a good and conscientious job. People who've never tried it have no concept of what a tedious chore it is, especially when maybe 75% of it is really dumb ideas. (Of course, *which* 75% is in the eye of the beholder...) This is why you don't see my name in the membership list for ANSI C -- I came close to joining but decided I simply didn't have the time. > How do you get to attend the meetings and present ideas? Pay the fee and show up. Actually you don't need to do either to present ideas -- standards committees pay some degree of attention to most anything that comes in the mail -- but it helps. >I never found > any addresses, schedules, contact points, meeting places or dates published in >normal industry traderags, or special magazines, like DR. Dobbs, >or PC week etc.... The information wasn't hard to find in programming-language publications, or here on the net for that matter. It's true that you won't find such things in Newsweek or its PC equivalent; the assumption is that the folks who are seriously interested will already be into programming languages to a reasonable extent, and paying attention. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
barmar@think.com (Barry Margolin) (02/18/90)
In article <1990Feb16.172805.24168@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <17950@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >> How do you manage to get onto a commitee like that? >Basically, you pay a modest fee, and show up for the meetings. ... > Having your employer's support helps >when it comes to the costs of attending meetings, but attendance in fact >isn't required, although it helps if you want to really have a voice in >things. ANSI rules say that you must have attended two of the most recent three meetings and be up-to-date in dues payments in order to have a vote on a standards committee (if the vote is taking place *at* a meeting the meeting in progress counts as one of the two). Is this what you mean by "really have a voice"? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
henry@utzoo.uucp (Henry Spencer) (02/18/90)
In article <34067@news.Think.COM> barmar@think.com (Barry Margolin) writes: >>... attendance in fact >>isn't required, although it helps if you want to really have a voice in >>things. > >ANSI rules say that you must have attended two of the most recent three >meetings and be up-to-date in dues payments in order to have a vote on a >standards committee ... Is this what you mean by "really have a voice"? Among other things; there is also the issue that being on hand to argue the merits of your idea is usually better than having to respond to criticisms after the fact by mail. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu