R
Richard Heathfield
Chris Hills said:
We could fix that.
<g,d&r>
We could fix that.
<g,d&r>
Why the C committee doesn't provide an implementation when the standard is published?
P
Peter Shaggy Haywood
Groovy hepcat lovecreatesbeauty was jivin' on 8 Jun 2006 20:40:08
-0700 in comp.lang.c.
Why the C committee doesn't provide an implementation when the
standard is published?'s a cool scene! Dig it!
Running on which system? Targetting which system? Hosted or free
standing? And how much are you willing to pay for this?
Tell me, how do you perform system dependant tasks (such as file
I/O, memory management, interaction with hardware, etc.) in standard
C? Each target system needs its own implementation.
--
Dig the even newer still, yet more improved, sig!
http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
-0700 in comp.lang.c.
Why the C committee doesn't provide an implementation when the
standard is published?'s a cool scene! Dig it!
Running on which system? Targetting which system? Hosted or free
standing? And how much are you willing to pay for this?
Tell me, how do you perform system dependant tasks (such as file
I/O, memory management, interaction with hardware, etc.) in standard
C? Each target system needs its own implementation.
--
Dig the even newer still, yet more improved, sig!
http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
P
P.J. Plauger
I once wrote an essay on the three basic meanings of "politics" --
briefly "damned politics", "jes' politics", and "enlightened politics".
But in the end *all* human interaction is politics, so railing against
it is like railing against the increase of entropy (which is defined
to be a property that practically *has* to increase).
Because the standards were *good enough* and to continue to oppose them
would have been counterproductive, even obstructionist.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
P
P.J. Plauger
Not when you make an inaccurate and dismissive statement (which was
accompanied by a similar statement in a separate posting). I felt
the glib dismissal needed to be countered.
Nope. It is well known that a heap of information of varying degrees of
accuracy can be used to distill remarkably accurate estimators.
But Google isn't as bad as you characterize it, not by a long shot.
(Would you have been as dismissive had it supported *your* viewpoint?)
I've found all sorts of algorithms, pizza parlors, addresses, definitions,
quotations, etc. etc. by Google searches and have verified repeatedly
that the ones that look sensible are mostly accurate, while the ones
that look fruity and nearly always fruity. Throw in the averaging effect
I cited above and you're a huge Hamming distance away from drivel.
Sorry, I was trying to be descriptive. Any insult was purely a bonus.
And now you're being patronizing.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
P
P.J. Plauger
I don't either and it hardly matters. What matters is the efforts that
have gone into defining the rules for calling C from C++ and conversely,
so you can share nontrivial data structures and partition a program
sensibly between the two languages.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
C
Chris Hills
I have been mentioning the Corporate Manslaughter Bill In presentationsRichard Heathfield said:
for some years now. I wish they would get it in to law.
It was not designed for SW but basically says are the Corporation
/managment using proper tools and processes. Proper safety procedures
etc.
It moves the blame from, in the case of the Zeebruger Ferry from the
deck hand who did not properly close the bow door or the Captain who as
a matter of procedure left the harbour whilst closing he bow door to the
management who wanted X crossings a day to be more profitable.
To save time to meet the requirement of X crossings a day the captain
had to leave harbour whilst closing the bow door on a RO-RO ferry.
Also the corporation had removed the car deck baffles.
J
jjf
Chris said:
I'm astonished. I've been participating in comp.lang.c on and off for
pushing 20 years; the 'off' periods have mostly been when I've been too
busy writing C code which had to run on several different processors
under several different OSes. I can't remember when I last wrote any C
code for which portability wasn't a consideration, if I ever have. At
this moment I'm taking a break from writing commercial C which will run
on 5 different processors (or at least 7 if you include the same
processor architecture operating at different word widths) under 5
different OS families.
It doesn't necesarily have to 'supersede'. That could be enforced by
whatever environment brings in legal or other obligations. That is,
contracts, safety law, or whatever could either specify "the most
recently approved whatever standard" or could explictly refer to a
particular one.
C
Chris Hills
It's true. Some people woke in an environment where portability is a
concern. A lot of the people like PJP who write libraries and components
etc do write portable code but the majority of the C I see is definitely
NOT portable. There is not point to having it portable and in fact if it
were portable C the programmer would probably be fired.
Why because in most embedded systems you are talking directly to HW
there is no OS. Their architectures require non standard C.
To write it as portable C would make it slower and larger. If Larger so
that it requires more memory it could add 50cents to a unit... over 100K
units a year that is 50,000 USD a year... that is why small and fast and
never mind the portability is way it works.
Besides once you have invested in the tools for a particular processor
IE compilers and ICE you don't want to buy a new set. the code is
usually "portable" to another MCU in the same family anyway.
It does by definition in ISO.
Where a specific version of the standard is not explicitly cited then it
is the current or latest. Ie C99 at the monment and depending on wording
with or without the TC's
MISRA-C for example explicitly specifies 9899:1990 + A1 and the two
TC's. Most other guides, contracts and legal requirements usually just
specific the current/latest version either explicitly or implicitly as
they don't want to have to update every time there is a "New and
Improved" version.
M
Morris Dovey
Chris Hills (in [email protected]) said:
| In article <[email protected]>,
| (e-mail address removed) writes
||
|| Chris Hills wrote:
|||
||| I rarely see portability high on anyone's list out side C.l.c
||
|| I'm astonished.
|
| It's true. Some people woke in an environment where portability is a
| concern. A lot of the people like PJP who write libraries and
| components etc do write portable code but the majority of the C I
| see is definitely NOT portable. There is not point to having it
| portable and in fact if it were portable C the programmer would
| probably be fired.
|
| Why because in most embedded systems you are talking directly to HW
| there is no OS. Their architectures require non standard C.
|
| To write it as portable C would make it slower and larger. If
| Larger so that it requires more memory it could add 50cents to a
| unit... over 100K units a year that is 50,000 USD a year... that is
| why small and fast and never mind the portability is way it works.
That's an interesting observation. My experience has been somewhat
different, in that I've been able to efficiently isolate processor-
and device-specific code and write the remainder in standard C. By so
doing, I've made possible the re-use of large amounts of expensively
produced code. One can isolate PHY-, MAC-, and timer-specific code and
implement the remainder of an ethernet driver portably. Interestingly,
rewriting large amounts of the code in a cable modem product as
standard C allowed turning on full gcc optimization resulting (all by
itself) in both smaller and faster code. I believe that since that
time, that firm has replaced the MIPS processor with an ARM and, if
so, very probably saved enough by reusing the standard-conforming
modules to make the $50K savings seem almost trivial.
In my next embedded system project, I wrote a p-code processor in
standard C that used an array of function pointers to dispatch /all/
of the hardware-specific functions which allowed that code to be used
to control all of the company's products that used embedded
controllers - where they had previously developed (from scratch)
complete software controller packages for each _model_ of every
product line. The expected short-intermediate term savings were huge
(I could happily retire on a new ocean-going yacht for less than 10%
of that.)
| Besides once you have invested in the tools for a particular
| processor IE compilers and ICE you don't want to buy a new set. the
| code is usually "portable" to another MCU in the same family anyway.
I'll agree with what you say about "want" and 'same-family
portability'; but there's often a (winning) business case for moving
on to newer, more-efficient architectures.
I'm not questioning the validity of your experience - just pointing
out that my own has been somewhat different.
| In article <[email protected]>,
| (e-mail address removed) writes
||
|| Chris Hills wrote:
|||
||| I rarely see portability high on anyone's list out side C.l.c
||
|| I'm astonished.
|
| It's true. Some people woke in an environment where portability is a
| concern. A lot of the people like PJP who write libraries and
| components etc do write portable code but the majority of the C I
| see is definitely NOT portable. There is not point to having it
| portable and in fact if it were portable C the programmer would
| probably be fired.
|
| Why because in most embedded systems you are talking directly to HW
| there is no OS. Their architectures require non standard C.
|
| To write it as portable C would make it slower and larger. If
| Larger so that it requires more memory it could add 50cents to a
| unit... over 100K units a year that is 50,000 USD a year... that is
| why small and fast and never mind the portability is way it works.
That's an interesting observation. My experience has been somewhat
different, in that I've been able to efficiently isolate processor-
and device-specific code and write the remainder in standard C. By so
doing, I've made possible the re-use of large amounts of expensively
produced code. One can isolate PHY-, MAC-, and timer-specific code and
implement the remainder of an ethernet driver portably. Interestingly,
rewriting large amounts of the code in a cable modem product as
standard C allowed turning on full gcc optimization resulting (all by
itself) in both smaller and faster code. I believe that since that
time, that firm has replaced the MIPS processor with an ARM and, if
so, very probably saved enough by reusing the standard-conforming
modules to make the $50K savings seem almost trivial.
In my next embedded system project, I wrote a p-code processor in
standard C that used an array of function pointers to dispatch /all/
of the hardware-specific functions which allowed that code to be used
to control all of the company's products that used embedded
controllers - where they had previously developed (from scratch)
complete software controller packages for each _model_ of every
product line. The expected short-intermediate term savings were huge
(I could happily retire on a new ocean-going yacht for less than 10%
of that.)
| Besides once you have invested in the tools for a particular
| processor IE compilers and ICE you don't want to buy a new set. the
| code is usually "portable" to another MCU in the same family anyway.
I'll agree with what you say about "want" and 'same-family
portability'; but there's often a (winning) business case for moving
on to newer, more-efficient architectures.
I'm not questioning the validity of your experience - just pointing
out that my own has been somewhat different.
W
William J. Leary Jr.
I've been programming, in C, since the 70's. Portability is always one of my
objectives, tempered by the target environment. The frequency with which I've
had to port to a new compiler or a new platform is frequent enough that doing
anything else is equivalent to write-once coding. This has, on several
occasions, allowed me to move a program from one platform to another so quickly
that people sometimes think I've "cheated" some how on the port.
On the non-imbedded side, I've had more than a few programs run successfully
on CP/M, MS-DOS, VMS and Unix, on Z80, 8086, VAX and Sun.
On the imbedded side I've had nearly identical code running on 8051's, Z80's
and Coldfires. I've also had the good fortune to work with someone who has
similar attitudes. He moved code from a 8051 (Implemented by yet another
engineer) to a MIPS then to a Coldfire with only those changes dictated by the
hardware, and did it quite quickly. I've lately come in to do maintenance on
the 8051 and Coldfire versions and further development on the Coldfire version.
The Coldfire is the second port of the 8051 code, but I find that my knowledge
of the 8051 code is applicable to the Coldfire code. And the other way around.
It's often possible to move source from one version to another and have it just
work.
The portions where I skip portability are either due to the application
(different features of the hardware, feature set, or OS) or performance. Even
then, I find that I can usually do something which will make it easier to port
later (isolation to a subroutine, #ifdefs for machine specific code, etc.) It
usually pays off in the end. Even in cases where it doesn't pay off in direct
ways, such as a quick port or knowledge reuse, it still pays off in that it
makes clear what's "just code" and what's specific to this machine or OS. This
has always helped people who came in from other environments see where they
need to apply their attention to learning new things as opposed to other areas
which are just C as they learned it.
However, there is truth in what you say. I often encounter portability as
having either been low priority or entirely ignored. I've usually found that
this was due to programmers with little breadth of experience, often (but
surely not always) these days with Windows. In the past it was MS-DOS. I'm
also starting to encounter more with Linux backgrounds. Lack of breadth, not
depth. They're often quite inventive, but simply don't see the advantages of
making it possible to reuse their hard won accomplishments in other
applications. Their ports, especially when the target count starts to rise,
then create source control nightmares.
- Bill
objectives, tempered by the target environment. The frequency with which I've
had to port to a new compiler or a new platform is frequent enough that doing
anything else is equivalent to write-once coding. This has, on several
occasions, allowed me to move a program from one platform to another so quickly
that people sometimes think I've "cheated" some how on the port.
On the non-imbedded side, I've had more than a few programs run successfully
on CP/M, MS-DOS, VMS and Unix, on Z80, 8086, VAX and Sun.
On the imbedded side I've had nearly identical code running on 8051's, Z80's
and Coldfires. I've also had the good fortune to work with someone who has
similar attitudes. He moved code from a 8051 (Implemented by yet another
engineer) to a MIPS then to a Coldfire with only those changes dictated by the
hardware, and did it quite quickly. I've lately come in to do maintenance on
the 8051 and Coldfire versions and further development on the Coldfire version.
The Coldfire is the second port of the 8051 code, but I find that my knowledge
of the 8051 code is applicable to the Coldfire code. And the other way around.
It's often possible to move source from one version to another and have it just
work.
The portions where I skip portability are either due to the application
(different features of the hardware, feature set, or OS) or performance. Even
then, I find that I can usually do something which will make it easier to port
later (isolation to a subroutine, #ifdefs for machine specific code, etc.) It
usually pays off in the end. Even in cases where it doesn't pay off in direct
ways, such as a quick port or knowledge reuse, it still pays off in that it
makes clear what's "just code" and what's specific to this machine or OS. This
has always helped people who came in from other environments see where they
need to apply their attention to learning new things as opposed to other areas
which are just C as they learned it.
However, there is truth in what you say. I often encounter portability as
having either been low priority or entirely ignored. I've usually found that
this was due to programmers with little breadth of experience, often (but
surely not always) these days with Windows. In the past it was MS-DOS. I'm
also starting to encounter more with Linux backgrounds. Lack of breadth, not
depth. They're often quite inventive, but simply don't see the advantages of
making it possible to reuse their hard won accomplishments in other
applications. Their ports, especially when the target count starts to rise,
then create source control nightmares.
- Bill
W
William J. Leary Jr.
Chris Hills said:
Only in those portions which contact the hardware directly. In most cases
quite large portions have, or with proper abstraction can have, no real
hardware dependancies.
I've rarely found this to be the case. When it is, the section gets isolated
in some way. If I'm really stuck (subroutine call too expensive, compiler
won't inline a function, etc.) I'll at least put a #ifdef around it hooked into
a global #define with the #else calling attention to the code.
But, as McCoy said, "I know engineers, they LOVE to change things." Well, I
known them too. If they can save two components and $1.00, they'll do it. And
in the overall scheme of things, they're probably right. When the MCU du-jour
blows away your tool set, it's good to be able to re-use 80% of your code and
concentrate on just the hardware differences and, usually, new features. The
inverse is true as well. When they want to save many thousands of dollars and
you tell them you can't because rather than port your code you'd have to
rewrite it, management takes a very dim view of your talents.
- Bill
D
Dave Vandervies
Any system with a C compiler, most likely.
A hosted system running in a bytecode-interpreted virtual machine (which
could be implemented in C) would make the most sense. (This would
also make it possible to re-use most of the VM code for a freestanding
implementation just by running it without the entry points for the
standard library and allowing a user-defined substitute for main()
as the entry point to the user code.)
This would, of course, require a C implementation to run on, but surely
there are enough of those out there. If that's too much to require,
then it could always be written to the previous version of the standard
instead of the new one.
An officially-endorsed reference implementation could be quite useful,
actually, even if it did require an already-existing C implementation
to run - especially if it's clear enough to be easily understood and
modified (as a base to work from for other implementations) and if it
aggressively tries to break bad code (as a sanity-checking tool for code
intended to be portable).
By calling the underlying C implementation, of course. How else would
you do it portably?
dave
A
av
there will be not the first time that people wrong
it is good if C/89standard is a subset of C++
but in that case why not consider only C++?
there is a difference between C and C++
the C language is writing the essential the C++ not
the only reason that i see for "to fail" of a my "constructor" is an
out of memory error. then if a program goes out of memory it has only
to save all it can save show a message and exit: right?
the peaple like "barocco" style but i not like it
i too
it is good if C/89standard is a subset of C++
but in that case why not consider only C++?
there is a difference between C and C++
the C language is writing the essential the C++ not
the only reason that i see for "to fail" of a my "constructor" is an
out of memory error. then if a program goes out of memory it has only
to save all it can save show a message and exit: right?
the peaple like "barocco" style but i not like it
i too