PE> It issues warnings. Even ISO C programs have warnings issued, for all
PE> sorts of things, on different compilers. A common one is if you go:
PE> if (c = 0) printf("xyz");
PE> It's legitimate ISO-C code, but most compilers will issue a warning
PE> that the "c = 0" is suspicious.
JG> Why would that be considered suspicious? Perfectly valid code
JG> should never be considered suspicious. In the end it's the
JG> programmer who takes responsibility for his code, not the compiler.
Because most likely you meant "c == 0". It is confusing to the
person reading your code too. Normally you would go ((c = func()) == 0) to
avoid the warning and make it obvious what you are doing.
JG> take a peice of recent code and try to compile it with a K&R
JG> compiler.
PE> Of course that doesn't work. The ANSI standard has been around since
PE> 1989. If you don't have access to a conforming C compiler, it's
PE> because you're on a dead system.
JG> 1989 is pretty recent when you stop to think about it. I
Not in terms of how long it takes vendors to get out compilers. You may
notice that C compilers exist on any machine you can buy today (new).
JG> One thing I've noticed in the C echos, which I've never come
JG> across elsewhere, is the way the standards are virtually a religion
JG> for some (a few) of you. I'm sure glad nothing like that has ever
JG> happened in assembly language programming. I think it must be born
JG> in mind that the object of writing a program is to acheive a given
JG> result, NOT to stick to any arbitrary standard.
The result people like me are after, is to be able to write programs,
without being tied down to one platform. Right at the moment I am using
OS/2. I used to be using MSDOS. Soon I will probably be using Linux. I
also use the Amiga and C64. At work, I use Unix (SunOS), but have also
used MVS, VMS, VM. Most of my programs will port to any of these
environments. I turn up to a job will all my tools.
PE> On a non-ISO (ie dead) compiler.
JG> I though rash statements were my department! No language or
JG> compiler is ever dead while anyone is still using it. Never! I
JG> have a language I wrote for the Plus/4 and C16 which is quite
JG> powerful and very fast. Although I'm the only person on the planet
JG> using it I can assure you the language is not dead.
"Relatively dead" then.
JG> For me that isn't much of a problem, I just want to write a
JG> Zmodem routine for Commodore 8 bit machines (C64, Plus/4 and C16).
JG> It will be rewritten in assembler anyway so I really just need the
PE> Ah, interesting! I am doing work on PDPZM at the moment, and I have
PE> gone to a lot of effort to keep the core Zmodem routines all using
PE> 100% conforming C code, so that it can be ported.
PE> Why do you need to rewrite that C code in assembler? Does the
PE> compiler produce really lousy code on (e.g.) PDPZM? Can you show me
PE> that?
JG> There are a number of factors to consider here. The fact that I
JG> don't have a C compiler (any variant) for the Commodores seems to be
JG> a fairly important point :) On the Commodores, especially the C64,
Can't you scrounge one up from somewhere? Surely you want one?
JG> speed of execution is paramount. The C64 has no UART, except as a
JG> software emulation, and has enourmous overheads in the interrupt
JG> routines. No compiler (any language) will ever be able to match a
JG> good assem programmer (with emphasis on the "good"). Assembly is
JG> more my native tongue, especially on the Commodores. In my
JG> application portability won't even be a consideration as the entire
JG> program will be (and must be) machine specific. The only comms
JG> routines I have for these machines are Xmodem, Kermit and an Xmodem
JG> variant of my own. None of those fit my requirements.
What you are talking about above is your comms routines, not the Zmodem
routines. I want to know why you would rewrite the Zmodem routines in
assembler.
JG> As I'm getting way off topic here I'm wondering two things. Who
JG> is the moderator of this echo and when were the rules last posted?
There is no moderator that anyone has ever heard of. The rules are:
1. Everyone should write ISO-conforming code or get told off.
2. No-one should criticize ISO.
3. Everyone should quote from the ISO spec when making points.
JG> I can't recall seeing the rules at all, although I've only been
JG> reading this echo for about eight months ;)
You're meant to read between the lines.
BFN. Paul.
@EOT:
---
* Origin: X (3:711/934.9)
|