S
Scott Moore
Please STOP crossposting to comp.lang.pascal.ansi-iso. This thread
has nothing to do with that forum.
Thank you.
has nothing to do with that forum.
Thank you.
On Sun, 17 Aug 2003 14:03:37 +0000 (UTC)
The HP Pascal I mentioned was *not* an embedded Pascal.
Anyway, as far as I'm aware all C implementations support the same
mechanism for separate compilation of modules so you don't have the same
problem.
The Texas Instruments implementation of C for the TMS320C1x/2X/5X was a
fully conforming implementation and even came with a copy of K&R2 as
part of the documentation set. This was at the same time I was dealing
with all those different Pascals...
Pascal is IMHO worse because the original definition did not include
support for separate compilation of modules. For this reason (and
probably others) K&R C is more likely to compile on a modern compiler
that supports ANSI C than Pascal written for any of the compilers I
mentioned.
This is irrespective of whether it was embedded or
non-embedded C or Pascal.
C & C++ are two distinct languages, yet you can link them relatively
easily...
So ANSI Pascal is largely irrelevant to the Pascal community ;-)
I bet you can use a lot of conforming C code not written for the 8051 on
an 8051, since I bet there is a conforming implementation.
I don't know about anyone else here, but I use the standard as a way of
ensuring that my code will run on multiple platforms with minimal
difficulty (I do have to use platform specific extensions in limited
areas) and not as an end in itself.
In C you can access most of the C code base whether it was originally
targeted for embedded or hosted environments. Obviously on an embedded
environment without a file system you can't use file oriented libraries,
but you could use some MD5 code written for a PC.
So do the majority of modern Pascal implementations support ANSI
standard Pascal?
Both VC++ and gcc can compile ANSI standard C (I don't know Keile C51)
so as long as you keep your implementation specific code isolated
(sometime I always try to do) then the bulk of your code will compile
and run correctly on both.
One major difference, almost all C compilers produced for a long time
have been able to compile ANSI standard C, I don't think the same can be
said about Pascal.
My experience was that *no* Pascal module compile on any compiler other
than the one it was written on because it would fail as soon as you
reached the line indicating it was a module rather than a program or as
soon as it referenced any other module, whichever came first.
Windows has Posix compatibility layers, depending on what you want.
also has GTK available if you want a common graphics handling code
between Windows and Unix.
As I say, I don't know Kiele, but it is possible to have code that can
be compiled by both VC++ and gcc. Look at Berkeley DB for one example.
Mark Gordon said:What if the JVM has not been ported to the processor you are using? Can
you find a JVM for any of the following processors?
Z80
6502
8051
TMS320Cxx
just to name 4 families of processor off the top of my head all of which
are used in *current* projects.
Even if you ported the JVM it would run like a snail on tranquilisers.
Also we had to upgrade from SCO 5.0.5 to SCO 5.0.6, something I'm told
was painful, on several customer sites in order to be able to run a
specific Java application. Java 1.4 is not available for earlier version
of SCO and was not available at that time for AIX, which another of our
customers uses.
As have the people talking about processors where the JVM is not
available.
One program I wrote in C for an embedded system was debugged by me on a
Silocon Graphics workstation by running the code natively (not in an
emulator or simulator). All I had to do was replace the two functions
that talked to the hardware with one function to read test data and
another to interface to a graphics library and display the results.
The debugged code then ran perfectly on the embedded system without any
further changes.
Some companies actually hold code reviews to ensure that code is well
written, and obstreperous abstrads like be *do* reject code and insist
on it being rewritten if the job has not been done properly.
If we don't hear from each language, may we assume that particular language
doesn't have all the necessary tools ???? <G>
Alan said:No, but you could assume not everyone wants to play your game.
Neither is VC++, or BC.
Hmm. Prototypes etc? Afaik K&R had no modules or prototypes at all,
the separate compilation were just externals, and parameters didn't
even had to match. (iow everything happened on linker, not langauge
level)
K&R is no standard. ANSI is.
That's not true afaik (but I'm no expert, just from the old BSD days).
Most K&R code mismatches or omits parameters between declaration and
compilation. This was only fixed with the formal prototypes in some
later standard.
Embedded versions are often simplified, and therefore often base
on older versions. Judging the state of Pascal by those is a bit odd.
C++ nearly includes C, even though they are formally separate
languages.
Link compability is a compiler/linker thing anyway though, and has not
much to do with the language. At least if the language wants to remain
portable You probably mean that C++ and C FROM THE SAME VENDOR
reasonably link well.
OTOH that is not a problem. Most Pascal compilers also link to C. They
probably also can link to eachother, only on a deeper level (directly
passing file handles instead of file descriptors etc)
In practice yes. But the Borland group, while it far outnumbers ANSI,
is x86 (and often even x86/win32) centric. So if you go outside x86,
you'll encounter quite a lot of ansi.
Maybe, but that would really strain those 256 bytes of memory.
Yes. It is a very limited help of trying to verify that. But in
practice, the standard is often not enough to build an average
application.
Quite a lot of code isn't very conforming (I can remember having to
fix nearly every program when I got an Alpha machine)
But except for that (and those original K&R code), you are somewhat
right, the problem is mroe that a fully standard C program is often
trivial, and no real app.
Something like that is nice to show to students, but not something for
IRL.
But that doesn't mean (and I don't mean to imply) that the standard is
useless, on the contrary, I think the C situation *is* better.
I do think however the magnitude of the differences (specially when
related to standards) is severely overrated.
Either that or Borland. Borland is proprietary, but so dominant that
smaller vendors (TMT,VP) follow it, and it also has following in the
open source community.
Sure, but that was not what I said. I said the compilers can't compile
an average program from the other.
And be fairly trivial.
No, and probably never will. I don't dispute that. I'm just saying it
is overrated.
Well, that is not my experience. The borland versions (generations is
a better world) are backward compatible till 1985, and ansi pascal is
pretty close to compability with even J&W pascal.
Sure. But that is not ansi isn't it?
(GTK on windows sucks, but)
GTK is also not exclusive to C. Actually the RAD of the pascal
compiler I use uses GTK on Unix platforms (but native winapi on win32)
Delphi does something similar, but uses QT.
As I say, I don't know Kiele, but it is possible to have code that
can be compiled by both VC++ and gcc. Look at Berkeley DB for one
example.
I can also craft Pascal code accepted by (nearly?) every compiler, so
what's the difference?
(well, there actually is. The string handling of that code
will be clumsy. char ident[x] based like C, and that is not how you
use strings usually under Pascal)
I used the Pascal byte code system, precursor and work-alike to modern
Java, on the 6502 and Z80. And yes, it did run like a snail on
tranquilisers. For that matter, so did highly tuned assembler and
compiled C.
Anyone who wants to license a reference implementation from Sun can do
so for $150,000, IIRC, and write a very think hardware layer to get
Java on thier chip/os.
Taking 20K for the JVM when you have a limited memory space could be a
problem. It would not run on the systems where we only had 8K of ROM and
2K of RAM.
Real reviews are mandated on projects for the military and for safety
critical projects. -and-
The application I am currently working on is several hundred thousand
lines of code and it runs on both big and little endian machines and
both Windows and a variety of Unix derivatives.
For the binary files the original author just chose one endianness and
wrote some code to explicitly read the files as bytewise as that
endianness.
We may have our own favourite Languages and we can poddle away in a corner
somewhere cutting code for the fun of it, but the real world demands that it
get solutions. By 2015 a new generation of development software will see
"programmers" removed from the loop and end users interacting and iterating
with smart software until they get what they want.
Procedural code is already into Gotterdammerung. It takes too long, requires
too much skill, is too inflexible (the accelerating rate of change in the
Marketplace and in technology is another reason why it is doomed to
extinction) and, overall, costs far too much.
LOL! I guess that would be quite appropriate, however, I refuse to engage inJC said:Hollerith Cards at dawn??
the JVM itself is written in C++,
Why assume a game was being played ?
Alan said:<top-posted on purpose>
Hey, guys, please remove comp.lang.c from your distribution list. We
have our own brand of flames, and yours are off-topic.
Unix-filter, as I am the only one using them. For that reason I am even
disappointed by the development that Delphi/Kylix has taken over the
last 10 years: Bigger, more complicated and worse documented. It may
help profesional programmers who need to make nice user interfaces. But
little guys like me who just need a job done were better off with good
old Turbo Pascal.
I hear what you are saying -- it is true of so many
environments.
As for Delphi, though, I've found it simple to create projects
that don't use any additional libraries -- that accounts for
about half of my Delphi projects. Tidy (but not necessary
tiny) console applications that rarely break 50k. To each his
own, but I don't want to give up my windows IDE, even if I'm
not programming a windowed application.
LX-i said:What? COBOL is obsolete? I guess OO and .NET are obsolete too...
True. As detailed in other responses.If it doesn't support fopen, then it's not a hosted C implementation.
True in C99, to which *very* few implementations (so far) conform, butIf it doesn't handle identifiers case-sensitively, then it's not a
conforming C implementation at all.
whats your point ? that java rnus on your mobile phone ?
<NEWS FLASH> C probably targets that too </NEWS FLASH>
and it also targets many that java does not run on ?
so what exactly *is* your point ? java runs on a *fraction*
of platforms that C targets.
does your mobile have under a K of ram ?
thought not
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.