Best C?
13 messages in this thread
Ben, there have been programs that I've seen that had two choices: either
write the whole routine in assembly, or have 2-lines of ILAC. In those
routines, I think the programmers made the right choice in using ILAC, as
it got the job done in the best way possible.
Of course any time you use ILAC you're creating machine dependent code, but
ILAC has in the past been a viable alternative to creating a whole function
in asm for all of two lines of asm code. This all reminds me of the
arguments w/ gotos that come up every once in awhile. Both ILAC and goto's
aren't evil forces created by Satan to tempt programmers into sin – they're
just language features that have been used in both positive and negative
ways. I myself have never had to code ILAC, but I know people who had, and
their products were better because of it – both from a readability and a
performance standpoint. I suspect that you may have been exposed to some
really horrendous ILAC early-on, and you assume all ILAC has to be that
way. Well, it doesn't, and it can be even elegant in certain limited
applications.
Finally, ILAC _is_ going the way of the dinosaur, as most of things it was
good for are being implimented directly into compilers (eg. interrupt
function in C). But please don't tell me that our compiler is junk just
because of the inclusion of an optional feature (optional=you don't have to
use it).
It's not junk – it's something that proliferates horrible coding, which is
something else again. The better choice, in _all_ cases, would have been
to code the module or whatever was required in asm, front to back (IF that
was required, which I doubt somehow… never seen something that peculiar
if ti was of any size). As for GOTO, haven't used that one in years… I
can see no use for it, either, except poor C skills.
I'm going to have to bow out of the argument here… leaving town monday
morning, will be gone for anywhere from 2 weeks to several months. I have
some foreign business arrangements to make in regards to some new products
of ours, and will be travelling extensively… IE, no CIS, at least at
first. Take it easy.
Are you saying that soon we will have a way, in legal C, to have a
routine that can be jumped to from a place external to the program, and
that will not only 'getA4', but preserve the registers as well? If so,
sounds good.
Actually, there always was a way in Aztec C. An interrupt routine, or
whatever, simply had to call the function intstart() at the beginning of an
interrupt function, and intend() at the end, and this would take care of A4
and everything else.
In version 5.0, we've simplified it by adding a #pragma which identifies a
function as being an interrupt handler. This will cause the compiler to
automatically generate code at the entry and exit points of the function
which gets A4 (only in small model!) and saves/restores registers.
Never heard of intstart() or intend() at all. Interesting. Will have to
take a closer look. A pragma?? Any rationale behind that? Pragmas are
almost as bas as ILAC.
#pragma's are ANSI approved ways to do things that aren't in the standard,
like specify special function types, direct the code generator, etc.
They're very nice, actually, in that they give an easy way to add
machine-specific stuff at the source-code level.
Alas, intstart() and intend() were not very well documented, and didn't
even make it in some manuals at all. Because our doc was in such a sorry
shape, we completely re-wrote and reformatted it all for the 5.0 release,
and I think they came out pretty well.
#pragmas are ANSI approved, but that doesn't make them A Good Thing. It
makes for non-portable code, or code that could appear to be portable, but
with fatal flaws in it, simply by virtue of the chance of an overlap of
naming pragma arguments in other compilers.
The best example I thought, though extreme to the point of silliness, was
"Your compiler has a #pragma called 'inline', that causes the compiler to
generate inline code for functions. Mine has a #pragma called 'inline' that
causes a format of the hard drive containing the code being commpiled" All
perfectly legal under ANSI standards (It is a standard now, BTW, in case
there are those reading this that don't know yet).
I saw the following on Usenet. It is the docuentation for the GNU C
compiler's #pragma directive.
The `#pragma' command is specified in the ANSI standard to have an
arbitrary implementation-defined effect. In the GNU C preprocessor,
`#pragma' first attempts to run the game `rogue'; if that fails, it tries
to run the game `hack'; if that fails, it tries to run GNU Emacs displaying
the Tower of Hanoi; if that fails, it reports a fatal error. In any case,
preprocessing does not continue.
So you're saying that all compilers should adhere strictly to ANSI, and be
completely non-innovative in every way? That everyone should code for the
2K embedded system with no I/O, just to make sure his code is
super-portable.
Get with it, Larry. This is the real world, where people are solving real
problems. #pragmas and other ANSI extensions were provided because ANSI
realized they _couldn't_ design the definitive language spec, because one
doesn't exist. Every machine has its flaws and strengths, and compilers
_have_ to be built with those flaws and strengths in mind. #pragmas such
as intfunc are designd, by nature, to be non-portable constructs that make
life on a particular machine (the Amiga, in this case) much easier. And
because #pragmas are _always_ implimentation defined, they are easy for a
maintenance programmer to single out when porting code.
People with your attitude seem to forget that programs aren't written for
the sake of art – they're written for _users_, who have very real and
concrete needs. And its the job of programmers to meet those needs, on
matter what it takes.
So far, the only time I needed a #pragma was in Microsoft 5.1 on the IBM.
I had 2 global vars that were modified by a external mouse driver to give
the mouseX and y coords. In the program I had 2 tight loops that access
these variables. Because volatle was not supported, and the compiler was
set to optimize for speed ( /Ox ), it optimized these right out of the
code! I had to turn off loop optimize with a pragma just before every loop
that accessed these volatle variables. Without these pragmas, I would have
to optimize without the loop flag for the whole program! Of course, if
Microsoft supported volatle, this would not have been needed.
As I understand it, Microsoft's #pragmas handle only optimization concerns.
The ones we've implimented are more along the lines of what Lattice has
done i.e., functional code generation over optimization. Our pragmas for
in-line calling of Amiga functions, register parameter passing, and
interrupt function definition all provide very useful functions that would
be difficult to impliment otherwise, and they provide a big pay-off in code
readability and execution time vs. other methods. So what's wrong with
that?
Why do you insist on putting words in my mouth? I do think that all
programs should indeed follow the standard for the language they are
written in. Please note that if you are claiming ANSI standard
compatibility, that you are perfectly free to use #pragmas to do virtually
anything you want. Please also note that it is dangerous, and should not be
used for things better left to #ifdef, macros, or reserved keywords.
What is my attitude that you claim to know so well Mike? It's bad enough
that you tell me what I am saying by extrapolating what I did say, but to
attribute an attitude to me because of your interpretations is going a
little far.
From statements like #pramgas=ILAC, I'd say generally negative. In what
way are pragmas dangerous? You have yet to point that out.
If by 'We' you mean Amiga users, we've had that for a while in Lattice.