>IIRC, C99 is upwardly compatible with C90, so there
are zero conversion
>problems in one direction. Obviously, using C99 constructs in C90
>programs can be a problem.
That's wrong. One simple example: In C90 you can do
int restrict=0;
and this is forbidden in C99.
It't the same with C and C++: In C you can do
int class=0;
and this is forbidden in C++.
>Which PC compiler vendor supports C99? I don't
know of one. I can't
>see much in C99 that's terribly useful, even though I am currently
>implementing some of it.
>
>
Ok, but a) it's not a pdf, i can do no search with Ctrl-f, b) it takes
more than 5 minutes to get it and
c) it costs 3 times more than the C99 from ANSI.
> Paul Curtis schrieb:
>
> >IIRC, C99 is upwardly compatible with C90, so there are zero
> conversion
> >problems in one direction. Obviously, using C99 constructs in C90
> >programs can be a problem.
> >
>
> That's wrong. One simple example: In C90 you can do
> int restrict=0;
> and this is forbidden in C99.
Indeed. It should have been called _Restrict as _Complex is. However,
you can port C90 to C99 and your C99 compiler will sure as hell have a
-c90 option for legacy code.
> It't the same with C and C++: In C you can
do
> int class=0;
> and this is forbidden in C++.
>
>
> >Which PC compiler vendor supports C99? I don't know of one.
> I can't
> >see much in C99 that's terribly useful, even though I am
currently
> >implementing some of it.
> >
> >
>
> GNU. I'm using gcc and only the C99 standard.
You're one angry guy. This group really isn't against you--yet...
;-)
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
Reply by Paul Curtis●March 15, 20042004-03-15
Rolf et al,
> >Just to set the record straight: The IAR tools
clearly
> states that they
> >support the standard ISO 9899:1990 and amendment 1:1994. That is
> >traditional standard C the way it looked before C99 was released.
> >
> >To indicate this the IAR tools sets the symbols __STDC__ and
> >__STDC_VERISON__ to 1 and 199409L, respectively. This is
> the intended
> >way to do this. ...
> > -- Anders Lindgren, IAR Systems
> >
> >
>
> I've got other things to do than reading the actual standard plus
> several ancient ones + converting standard C code from one
> standard to
> another.
IIRC, C99 is upwardly compatible with C90, so there are zero conversion
problems in one direction. Obviously, using C99 constructs in C90
programs can be a problem.
> The current standard, wich is 5 years old, is
> enough, even for
> compiler vendors and the PC compiler vendors have no problem
> with C99,
> as far as i know.
Which PC compiler vendor supports C99? I don't know of one. I can't
see much in C99 that's terribly useful, even though I am currently
implementing some of it.
> There is also a practical reason why i don't
use C90: I can't
> get it; on
> www.ansi.org i can get only C99: http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC
+9899%2D1999
You can get C and C++ standards from from Wiley too:
This may be cheaper for printed copies than ISO, but ISO charge only a
few CHF for an electronic version of the standard.
> And from a high price compiler like the one from
IAR I
> do expect that it's actual, not ancient.
You have the option not to purchase, as does everybody else. However,
C99 is not common. If everybody wanted C99 compilers, it would be
higher on the agenda for all vendors.
Reply by Rolf F.●March 15, 20042004-03-15
Hi,
>Just to set the record straight: The IAR tools
clearly states that
>they support the standard ISO 9899:1990 and amendment 1:1994. That is
>traditional standard C the way it looked before C99 was released.
>
>To indicate this the IAR tools sets the symbols __STDC__ and
>__STDC_VERISON__ to 1 and 199409L, respectively. This is the intended
>way to do this.
>...
> -- Anders Lindgren, IAR Systems
I've got other things to do than reading the actual standard plus
several ancient ones + converting standard C code from one standard to
another. The current standard, wich is 5 years old, is enough, even for
compiler vendors and the PC compiler vendors have no problem with C99,
as far as i know.
There is also a practical reason why i don't use C90: I can't get it;
on
www.ansi.org i can get only C99:
And from a high price compiler like the one from IAR i do expect that
it's actual, not ancient.
Rolf
Reply by Anders Lindgren●March 15, 20042004-03-15
> it seems you didn't try using the IAR
debugger while using the UART
> (which does not work even at 2 other colleagues, 4 different PCs and even
at 300
> Baud) or to use some standard conforming C code with the IAR compiler.
> One typical example: Today i had to change
>
> for(int i=0; i<1234, i++);
>
> because the IAR compiler does not accept this C99 code.
> Last month the main problem was that the IAR compilers don't know the
qualifier restrict although the standard says that even a freestanding
conforming implementation has to know the qualifiers const, volatile AND
restrict.
> Because the ANSI/ISO-C standard allows to ignore the qualifier restrict,
> it's strange that the IAR compilers (even the 2.x versions)
don't
> know restrict. And it seems that the IAR guys don't know the
standard
> because the IAR compiler do set __STDC__ to 1 which is definitely wrong!
> Another point is that the IAR compilers are poor, they don't have e.
g.
> stdbool.h.
Just to set the record straight: The IAR tools clearly states that
they support the standard ISO 9899:1990 and amendment 1:1994. That is
traditional standard C the way it looked before C99 was released.
To indicate this the IAR tools sets the symbols __STDC__ and
__STDC_VERISON__ to 1 and 199409L, respectively. This is the intended
way to do this.
Concerning the "restrict" keyword. We have decided not to recognize
it until we have full support for it. Until then, applications that
contain the "restrict" keyword can be compiled by simply defining
"restrict" as an empty preprocessor symbol.
Note that even though we do not support the full C99 standard, the
current compiler and the library do support some of the features of
C99. The upcoming V3.10A release do support even more, including the
"stdbool.h" header file.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by onestone●March 12, 20042004-03-12
It's an ancient piece of kit that I built in 1994 when I was doing some
particularly strange things with engine management. It's very simple,
the hardware side CPU's are programmed in a similar manner to relay
ladder logic from a PC. The PC software is DOS based, and allows me to
upload stored results then play with them in various ways. It's a very
crude 64 channel logic analyser with built in signal injectors, thats
all. It's not as good as a logic analyser at pure logic analysis, glitch
capture etc, and has only limited signal injection capability. But it's
better than a scope. I must admit I don't use it on simple jobs, as it
was built as a quick and dirty fix for one job 10 years ago, and is
pretty cumbersome. The problem with commercialising anything like this
is that it would work out to be quite expensive, and would have a very
small market. Anybody here could go and buy a multichannel PC-Scope,
build a power supply, add some 4051 or similar muxes and do the same
probably for less.
Al
Reply by Leonard Braun●March 12, 20042004-03-12
Al,
Your Hardware simulator sounds very impressive!
Perhaps you ought turn it into a marketable product:)
"The hardare simulator takes me beyond the limitations of a software
simulator, and lets me test a system in a way not available in any other
way. For example I can set up an input pulse for capture, and view any
I/O associated with the event, with as many occurences as I like
overlayed. This can show misssed interrupts, jitter, odd timing
conflicts, and problems in processign sequence."
Reply by onestone●March 12, 20042004-03-12
J.C. Wren wrote: > Y'all are just going to argue until
you're blue in the face. The
> whole thing about goto is absolutely silly, when you're comaring a
HLL
> to assembly.
Yes, but it's fun.
You cannot build a Turing complete processor without > looping constucts. Goto's in HLLs are
considered unstructured. Jumping
> in and out of assembly routines that are not defined as clear entry and
> exit points is unstructured. I've been writing assembly and C for
over
> 25 years.
You old bugger you!, I've only written in C for 20, and assembler about
25, but I did write in binary for nearly 10 years before that (I'm 39 by
the way). I was too poor to buy an assembler even if they'd been
available, so when I found my first assembler (built into an ICL 2960
engineers processor) I thopught it WAS a HLL.
> I've seen very few cases where goto in C was
applicable. I
> think it's silly to say that it's a contrived example that
doesn't have
> a goto.
Of course, it doesn't have one at the highest level, and yes I was being
pedantic, you may call it silly if you like :*(
>
> Often I agree with Al, except on a few points. This is not one of
> them: "If I've correctly designed my program, or hardware or
> whatever I shouldn't need to rely on someone elses tools to check
it."
That isn't quite what I'm saying. Obviously, to a certain extent, I
rely
on third party tools, but endlessly chucking tools at code doesn't
necessarily improve things. I have a set of tools that suits me. This
includes an assembler, a customised "spell checker" (written in C on
the
Pc by the way), a modified FET board that allows me to inject signals
into any pin, and read back all pin states in analog or digitised form,
and a massive library of tested routines.
The spell checker runs after my programs compile correctly. Because I
have some coordination problems with my hands I generate typoes all the
time. This hunts out typoes that assemble legally, but which are incorrect.
The hardare simulator takes me beyond the limitations of a software
simulator, and lets me test a system in a way not available in any other
way. For example I can set up an input pulse for capture, and view any
I/O associated with the event, with as many occurences as I like
overlayed. This can show misssed interrupts, jitter, odd timing
conflicts, and problems in processign sequence.
The spell checker didn't exist in a form that suited me, it is
configurable for any instruction set/assembler with minimum effort.
hence I had to create it. Same goes for the hardware simulator. It
didn't exist so I built it.
> Depending on what level you take that, your
assembler/linker doesn't
> need to bother checking that relative jumps are in range, because, well,
> you've written it so well. MASM and OPTASM both tell you when you
try
> to load BL from an variable that was defined with .word. If you
didn't
> mean to do that, you qualify it with a byte keyword. It's all a
matter
> of degrees.
>
> It's pretty safe to say that Al doesn't like HLLs. I've
written so
> much assembly, I'm over it.
On the contrary I love them, in their place. And, for the work I do, and
the way I work, microcontrollers are not the place. Over the years I've
tried many HLLs, from the old ALGOL, FORTRAN, and COBOL, through many
varieties of BASIC (even VB6), PROLOG, LISP, ADA, C, PASCAL (YEUK),
PILOT. Of these C is by far my favourite. I do honestly like C, although
I think C++ is the biggest curse ever to infest a computer.
> It's pretty evident to me that most of Als
projects are single
> person. When you have 10 people working on a software project, you
> CANNOT use the same techniques nor exhibit the same control.
Only now, often in the past I had at least one and up to 20 more
programmers working for me, although I usually stripped that down. I
don't think large teams are efficient. I prefer no more than 4 people
even on huge projects.
> You can't
> assume everyone is as good as you.
You can't even assume you're as good as YOU think you might be. When
I
worked with others I always had people cross testing code.
If you say "Fred, write a string > copy routine", you have to assume Fred is
going to do it well enough
> that it works.
But if, instead of giving Fred an undefined carte blanche to create a
string copy routine, and possibly ending up with quite a yarn (pun,
sorry) you say "Fred, write a string copy routine, these are the input
conditions, these are the output conditions and this is the test suite
it must pass." You have a far better chance of getting back what you
want.
If you don't trust Fred and you back to re-write what he > wrote, you may as well not have hired Fred in the
first place.
I wouldn't have hired him if I didn't trust him, and, even if he was
a
clients employee I wouldn't use him for anything I felt he couldn't
handle. I would, however try and teach him the right way to do things.
hat way's that? My way of course ;!}
And this > where languages like Ada and Modula-II and
Modula-III shine. Clearly
> defined interfaces, package specifications, etc. C++ offers much of
> that, but I'm not much on C++ (straight C guy here). There's no
way to
> enforce library interfaces in assembler, that I've ever seen. You
> either push data on the stack, or setup registers and call. No type
> checking. Did you and Fred really have the same idea what string copy
> should do? Especially in a Harvard architecture machine...
Yes if the intitial design and specificationwas done correctly.
>
> Ada does not have to be inefficient. There is nothing intrinsically
> more inefficient in Ada than any other true HLL, be it Pascal, Module,
> Cobol, Fortran, whatever. Yes, there are inefficient Ada compilers.
> There are also some very very good ones (Janus, I think? Can't
recall
> the name). But you can also write inefficient code in any language,
> including assembler.
I've never disputed that
You can write poor algorithms, you can fail to > have an understanding of the instruction
schedulers (and incidently, it
> is considered for all practical purposes that a human can no longer
> write efficient scheduled code for Pentiums and up.
Sounds almost like a challenge worth taking up. :~>
There are very few > cases where the code generated of a compiler
produces worst code than a
> human, in regards to instruction scheduling), or while you may like a
> single instruction store indirect and post decrement, it may actually be
> slower than two consecutive instructions (there's a couple of common
x86
> examples of this).
>
> I've seen this conversation come up three or four times, and
it's
> like watching two brick walls trying to convince each other to move.
> Just ain't gonna happen.
Of course not, but, like gridiron it's fun watching them collide.
>
> --jc
With those initials how could I argue?
Hail Mary, here comes the long bomb
Al
Reply by J.C. Wren●March 12, 20042004-03-12
Y'all are just going to argue until you're blue in the face. The
whole thing about goto is absolutely silly, when you're comaring a HLL
to assembly. You cannot build a Turing complete processor without
looping constucts. Goto's in HLLs are considered unstructured. Jumping
in and out of assembly routines that are not defined as clear entry and
exit points is unstructured. I've been writing assembly and C for over
25 years. I've seen very few cases where goto in C was applicable. I
think it's silly to say that it's a contrived example that
doesn't have
a goto.
Often I agree with Al, except on a few points. This is not one of
them: "If I've correctly designed my program, or hardware or
whatever I shouldn't need to rely on someone elses tools to check
it."
Depending on what level you take that, your assembler/linker doesn't
need to bother checking that relative jumps are in range, because, well,
you've written it so well. MASM and OPTASM both tell you when you try
to load BL from an variable that was defined with .word. If you didn't
mean to do that, you qualify it with a byte keyword. It's all a matter
of degrees.
It's pretty safe to say that Al doesn't like HLLs. I've written
so
much assembly, I'm over it. I enjoy writing in C. I like creating a
structure, inserting a variable in the middle of it, compiling it, and
having everything fixed up. None of that old school "thisloc equ
lastloc + 1" (OPTASM was the only assembler I've ever used that
actually
support structure like definitions. It was great) or other games with
equates to define pseudo-structures. It's not a crutch. It's
convienence. And if the assembler can off-load some detail work, it
should. And I'll use it.
Strong typing and agressive type checking are two different things.
Strong type is when you have to call methods or play really wierd stuff
to get from one type to another. Pascal has strong typing. C has/can
have agressive type checking. I like agressive type checking. If I
really want to convert one type to another, I'll use a cast. Then the
compiler shuts up. Otherwise, it's doing it's job, rightfully and
righeously assuming I've done something questionable, and did I really
mean do do that?
It's pretty evident to me that most of Als projects are single
person. When you have 10 people working on a software project, you
CANNOT use the same techniques nor exhibit the same control. You can't
assume everyone is as good as you. If you say "Fred, write a string
copy routine", you have to assume Fred is going to do it well enough
that it works. If you don't trust Fred and you back to re-write what he
wrote, you may as well not have hired Fred in the first place. And this
where languages like Ada and Modula-II and Modula-III shine. Clearly
defined interfaces, package specifications, etc. C++ offers much of
that, but I'm not much on C++ (straight C guy here). There's no way
to
enforce library interfaces in assembler, that I've ever seen. You
either push data on the stack, or setup registers and call. No type
checking. Did you and Fred really have the same idea what string copy
should do? Especially in a Harvard architecture machine...
Ada does not have to be inefficient. There is nothing intrinsically
more inefficient in Ada than any other true HLL, be it Pascal, Module,
Cobol, Fortran, whatever. Yes, there are inefficient Ada compilers.
There are also some very very good ones (Janus, I think? Can't recall
the name). But you can also write inefficient code in any language,
including assembler. You can write poor algorithms, you can fail to
have an understanding of the instruction schedulers (and incidently, it
is considered for all practical purposes that a human can no longer
write efficient scheduled code for Pentiums and up. There are very few
cases where the code generated of a compiler produces worst code than a
human, in regards to instruction scheduling), or while you may like a
single instruction store indirect and post decrement, it may actually be
slower than two consecutive instructions (there's a couple of common x86
examples of this).
I've seen this conversation come up three or four times, and it's
like watching two brick walls trying to convince each other to move.
Just ain't gonna happen.
--jc
Reply by onestone●March 12, 20042004-03-12
Richard (UK) wrote: >>>Of course. Like 'GOTO IS A SIN',
'STRONG TYPING IS GOOD', 'OBJECTS ARE
>>>EVERYTHING', 'AUNT ADA IS A SAINT' etc etc, all the
religious
>>>incantations I have heard over the last 30+ years.
>>>They are all crap.
>
>
> Not so sure about that ... these systems/ideas come from some really
bright
> & experienced developers ... they can't all be wrong
Most crawled out from university courses, or other people with axes to
grind.
> - "Goto is a sin" was essentially an
attack on "spagetti coding" rampant in
> the 60's
You cannot, at the end of the day avoid goto. I haven't yet met a micro
that didn't have a JMP or BRA instruction, which is a GOTO, or a program
that could live without one, that wasn't seriously contrived. On the
other hand I have seem some abominations where people have tried to
avoid using GOTO.
> - Strong typing catches errors - and forces good
design.
Enforced strong typing can stuff a design. It is there to prevent those
who can't control their code, or who don't truly understand what
they
are doing from making simple mistakes. Once you pass the simple stage
strong typing can inhibit efficient code design.
> - Objects are of course crap [you put that one in
to trip me up!]
;@}
> - Ada is great ... I have used it ... it's
the only language which really
> DOES prevent most [not all] errors from reaching the linking stage
Tell that to Airbus, and many hundreds of other products (especially
military) that relied on ADA instead of relying on good base design
processes. I too used ADA many moons ago, but swore off it's
inefficiency.
>>Use the tools that do the job, as long as you
understand how to use
>>>them, and the potential future pitfalls they may create.
Of course, this is the point. Nothing is bad if you understand it
thoroughly, and know when and when not to use it. Teaching otherwise
produces crippled students.
>
> You are lucky: you have the skills to do a good job without any form of
> support ... but what happens when you are tired, it's 4 in the morning
and
> the client is collecting the code at 10? Wouldn't it be nice if Aunty
Ada or
> whatever caught that tiny slip of the fingers?
I'm normally awake at 4 in the morning (if you trace my posts I
don't
think you'll find a time I'm not awake!!!) I wouldn't allow my
client to
think he could collect code until it was ready
>
> I'm not proud - I'll adopt almost any technique or let any bit of
checking
> software run to prevent any foul ups!
I'm proud of what I do, and I'll adopt anything that I consider to
be
efficient, however If I've correctly designed my program, or hardware or
whatever I shouldn't need to rely on someone elses tools to check it.
Those tools may, at worst, have bugs, and at best induce a false sense
of security.
