C90 penetration

[Bart van Ingen Schenau]

... snip ...



Sure it is.  It just returns a run-time error.  

On a freestanding implementation without <stdio.h>, that would give a
compile-time error.

This means indeed that the classic Hello World program is not portable
to all imaginable platforms.
In practice, this is not a problem, because those platforms that don't
have <stdio.h> usually don't have any means of performing I/O at all,
so the Hello World program is meaningless for them.

Bart v Ingen Schenau

 

[James Kuyper]

On a freestanding implementation without <stdio.h>, that would give a
compile-time error.

I was actually commenting about hosted implementations - but it would of
course be pointless to "conform" to the requirements for a hosted
implementation in such a meaningless way. This is a DS9000 option, not
something any reasonable implementation would do.

This means indeed that the classic Hello World program is not portable
to all imaginable platforms.
In practice, this is not a problem, because those platforms that don't
have <stdio.h> usually don't have any means of performing I/O at all,
so the Hello World program is meaningless for them.

If you want to do I/O, the absence of any ability to do it is a problem.
It's not a problem created by C - it's a feature of the architecture -
but that doesn't make it any less of a problem.

 

[Bart van Ingen Schenau]

I'm interested to know what platforms exist that don't have a free
C90 compiler yet.
[...]

     You'll have to define "platform" to get a meaningful
answer.  The computers in my automobile engine, for example,
probably don't have free C compilers.  Not sure about my
mobile phone, my television, my cable modem, ...  All these
are programmed,

Ok - two definitions.

1. A platform that has a native assembler and editor that
people use to write and compile assembler code.

2. Any system that has assembler code currently being written
for it.

Basically my goal is to make assembler optional instead of
mandatory for non-speed-critical code.  Starting with platforms
in category 1.  Then doing 2.

It does not fit your two categories, but the Bluetooth chipsets from
CSR do not have a freely available C compiler.
OTOH, the compiler is included in the SDK, and only a company with too
much spare cash would consider not buying the SDK for their
development.

BFN.  Paul.

Bart v Ingen Schenau

 

[kerravon]

Forth is an assembler/disassembler/debugger/interpreter. It does it
all. You may not be employing a very precise definition of
interpreter.

I read in gforth's article that the bar was raised when
commercial forth compilers started producing machine code.

So, that's apparently not universal.

I think the word "they" is leading to sloppy thinking. The first
implementation of forth was on punch cards. He didn't use C to port
it; he used a cardboard box.

It's one of the active forth implementations.

And at the end of the day, I'm going to have to ask - where
is the freely-available MVS implementation of forth such
that I can take a CRC-calculating routine, originally written
and tested on say Unix, then compile it on MVS into
assembler/machine code?

That's what the portable language I'm after needs to do.
Be a substitute for the application logic that would otherwise
be done in assembler, and be portable to an alien machine,
and be AVAILABLE on that alien machine (at least, no
financial barrier preventing it from being available).

With all due respect, the fact that gforth is implemented in c is, if
anything, a stronger reason to investigate what micros have a forth
but not C.

And? Do you know of one? It sounds like all we have
remaining is having to use a subset of C90 on the
C64. That, and DOS/VS(E).

Then forth could be your lingua franca for all of them.
I misremembered the article I mentioned. It's called "Moving Forth".
So you don't have to search, try here:

http://www.bradrodriguez.com/papers/

And wikipedia has a nice overview of all the wonderful things it does.

http://en.wikipedia.org/wiki/Forth_(programming_language)

I had already seen this latter, which is how I ended up on gforth.

From your "moving forth" link we have:

http://www.bradrodriguez.com/papers/moving4.htm

"a new trend: Forths written in C. These have the advantage of being
more portable than assembler -- in theory, all you have to do is
recompile the same source code for any CPU."


As well as MVS, a number of other systems (e.g. Cray) have come
up in this thread. Do they have either a freely available forth too,
or if not, one that comes as standard?

BFN. Paul.

 

[kerravon]

Where humanity is concerned, it is (almost) never true to say that
all X are Y. I don't know whether C compilers are bundled with
Crays. Nevertheless, logic comes to our aid here: Crays are a big
deal, economically speaking, and in comparison C compilers for
Crays are likely to be only a little deal - delta at the outside,
and possibly only epsilon. I would imagine it would be quite
difficult to find a C-using organisation that, having spent a few
millions on a C-less Cray, is then daft enough to refuse to spend a
few thousands on a C compiler for it.

The trouble is that they may not be a C-using organization.
That's the problem with MVS too - almost everywhere is a
Cobol-using organization. The small number that aren't, are
PL/1. Then there's assembler.

Choose your poison when you want a utility to unzip a file,
when you've already got that C code on Unix, but not on MVS.

If Fortan was standard on the Cray, then Cray programmers
could well be out of luck too.

But it sounds like it's almost all covered. The most is that
some C64 hobbyists, who probably don't want floating point
anyway, have to live without floating point.

And MVS users need have to live with some compiler bugs
because there's no-one available to fix the compiler
internals at the moment.

Plus DOS/VS(E) users who can still be out in the cold
completely.

BFN. Paul.

 

[Keith Thompson]

You miss the point; if 'double' were indeed a typedef for a struct
containing a char array, then the above initialization would normally
be acceptable; however, according to the C standard, such code is a
constraint violation for which a diagnostic is required. The compiler
could disallow, or at least diagnose, such code as a special case, but
it would require special-case handling.

And there are a number of other reasons why making "double" a typedef
for a struct type would make a compiler non-conforming. Two examples:
"double" could be used as an ordinary identifier at block scope
(hiding the typedef), and "long double" would be a syntax error.

Of course a compiler could implement double as a struct, generating
either inline code or calls to library routines for various
operations, but the struct declaration would have to be hidden from
user code.

 

[Walter Banks]

I still expect assembler to be used in some low-level
situations, and to be called from C.

Why is that necessary? Using the current standards
every machine code can be generated directly from
C. No assembly needed, and lots of good reasons not
to use it.

Regards,

 

[Keith Thompson]

Bart van Ingen Schenau wrote: [...]

This means indeed that the classic Hello World program is not portable
to all imaginable platforms.
In practice, this is not a problem, because those platforms that don't
have <stdio.h> usually don't have any means of performing I/O at all,
so the Hello World program is meaningless for them.

If you want to do I/O, the absence of any ability to do it is a
problem. It's not a problem created by C - it's a feature of the
architecture -
but that doesn't make it any less of a problem.

In theory, it could be a feature of the implementation, not the
architecture. For example, one could easily have a freestanding
implementation without <stdio.h> on, say, a Unix-like platform that
could support a hosted implementation. In practice, of course, hosted
implementations for such platforms are readily available.

 

[Keith Thompson]

Why is that necessary? Using the current standards
every machine code can be generated directly from
C. No assembly needed, and lots of good reasons not
to use it.

The C standard doesn't guarantee that every machine code can be
generated directly from C.

 

[robertwessel2]

And at the end of the day, I'm going to have to ask - where
is the freely-available MVS implementation of forth such
that I can take a CRC-calculating routine, originally written
and tested on say Unix, then compile it on MVS into
assembler/machine code?

Well, I did a (limited) Froth variant for the mainframe a number of
years ago for executing the test harness code for some of our
communications stuff, so it would be more-or-less possible.

But ANSI Forth requires ASCII, and is specifically incompatible with
EBCDIC. To whatever extent that means anything in the Forth
community...

And? Do you know of one? It sounds like all we have
remaining is having to use a subset of C90 on the
C64. That, and DOS/VS(E).

BTW, it hasn't been "DOS" or "DOS/VS(E) in a couple of decades. "VSE/
ESA" until a couple of years ago, now "zVSE". There is a C compiler
from IBM, although it's not free.

 

[kerravon]

Why is that necessary? Using the current standards
every machine code can be generated directly from
C. No assembly needed, and lots of good reasons not
to use it.

The interface to the MVS operating system is defined as
assembler macros, e.g. GETMAIN to obtain memory. Even
if the standards you mention allow a GETMAIN to be
generated for later assembly, I consider that to be
assembler coding, not C. It's not portable regardless.

It's the non-machine-specific portion of application
logic that I wish to truly be portable by virtue of
being implemented and available.

On the unrelated topic - I looked closer at Forth. For
all the complaints about C's use for programming (being
terse, or unmaintainable) - it's streets above Forth!!!.

C remains the strongest contender for a lingua franca,
and appears to be very close to universal.

BFN. Paul.

 

[kerravon]

In which case, why on earth would they need a C compiler?

Because they have a utility that they need, that isn't part
of their normal business application. E.g. a hexdump program,
for the programmer to make his life easier.

100% of the MVS sites I've worked on have had C/370 installed, and
some have had LE370 (another C compiler) installed as well.

LE/370 is the language environment. Basically the C runtime
library (also PL/1 etc). That is probably near-universal on
modern systems (but not the older public domain systems that
are now in active use).

(Having
said that, if they didn't, I wouldn't have been working there, so
it's not as impressive a statistic as it might seem.)



Everybody and his dog interfaces to MVS via a PC. Unzipping is not
normally a problem.

It is if you want to do the unzip on the mainframe, of a file
you just zipped on the PC so that you don't have to transfer
the files one at a time!

Incidentally, the lack of a free C compiler prevented people
like the info-zip project from maintaining the MVS port.

zip was only one example anyway. What if I want to calculate
the CRC of a file on the mainframe? Or do a hex dump of it.
Especially if the person is new to MVS, but has the exact
code they need on a Unix system.

BFN. Paul.

 

[Walter Banks]

The C standard doesn't guarantee that every machine code can be
generated directly from C.

This is true, however one of the tests we are currently
doing as we implement new targets is to write code
in C that is functionally a statement(s) for each
processor opcode and make sure the generated code
is a single instruction.

This goes a long way to eliminating the need for assembler
in application code.

Regards,

 

[kerravon]

Well, I did a (limited) Froth variant for the mainframe a number of
years ago for executing the test harness code for some of our
communications stuff, so it would be more-or-less possible.

So, doesn't exist yet.

But ANSI Forth requires ASCII, and is specifically incompatible with
EBCDIC.  To whatever extent that means anything in the Forth
community...

And a standard implementation can't exist on 3 major platforms.

BTW, it hasn't been "DOS" or "DOS/VS(E) in a couple of decades.  "VSE/
ESA" until a couple of years ago, now "zVSE".  

That's what IBM markets it as, not necessarily what the
programmers call it. MVS became OS/390 then z/OS, but
everyone still talks in terms of MVS, since that is the
programming interface.

There is a C compiler from IBM, although it's not free.

Right. So some sites literally don't have a C compiler.
Nor can a lone programmer cost-justify it on the basis
that he has some utilities he wants to bring across.

But a free C compiler he can just install himself.

BFN. Paul.

 

[robertwessel2]

On Mar 28, 10:11 am, "(e-mail address removed)"

That's what IBM markets it as, not necessarily what the
programmers call it. MVS became OS/390 then z/OS, but
everyone still talks in terms of MVS, since that is the
programming interface.

If we're going to go that route, lot's of people (especially
programmers) still call it OS (or Ozzy), from the *pre* MVS days - and
"MVS" was OS/MVS after being OS/VS2 after being OS/MVT... And just to
keep everyone hopping, it went back to OS (OS/390) for a while between
MVS/ESA and zOS.

 

[Walter Banks]

On the unrelated topic - I looked closer at Forth. For
all the complaints about C's use for programming (being
terse, or unmaintainable) - it's streets above Forth!!!.

Forth has a lot of series reliability terms. Elizabeth Rather
has defended forth strongly and backed it up with some
impressive applications work. Much of forth's success
depends on a lot of personal discipline writing applications.

C remains the strongest contender for a lingua franca,
and appears to be very close to universal.

That is probably true. Restricting it to FOSS in the long
term hurts language development by reducing the
acceptable risk for innovation.

Regards,

 

[CBFalconer]

.... snip ...

This means indeed that the classic Hello World program is not
portable to all imaginable platforms. In practice, this is not
a problem, because those platforms that don't have <stdio.h>
usually don't have any means of performing I/O at all, so the
Hello World program is meaningless for them.

Not so. Nothing prevents someone producing a routine that puts a
character on a screen and advances the screen location. This is a
sufficient interface for HelloWorld. Happens every day in the
embedded world.

 

[kerravon]

That is probably true. Restricting it to FOSS in the long
term hurts language development by reducing the
acceptable risk for innovation.

Pardon? Which thing is being restricted to free and
open source software and what risk?

BFN. Paul.

 

[kerravon]

kerravon said:



At which point they become a C-using organisation, so it's time for
them to invest in a C compiler.

No, a single programmer is unable to trigger the paperwork
and money and support required to get a commercial C compiler
installed. He will be told to use PL/1 or assembler etc
instead.

However, no-one (especially his immediate boss) cares if
he uploads 700,000 lines of assembler code, then does a
bit of this and that, then ends up with 1000 lines of
assembler and says "Ok, I've got that assembler utility now".

That's how things tend to work.

Even on sites that don't have a batch transfer mode, it's pretty
trivial to write a wrapper around the file transfer mechanism.

Well, I upload stuff to a z/VM system via c3270. I manually
initiate the transfer after pressing ctrl-[.

There may well be a way to automate that, but I don't know it.

That program appears to mangle file transfers though, because
it seems that it opens a file in text mode instead of binary.

So prior to doing the transfer, I do a hexdump (sort of) of
the zip file. However, for some reason, text mode transfers
don't work either, so I do the conversion to EBCDIC in
advance.

Theoretically I could transfer the 400 or 500 files up one
by one instead of using zip.

But I found a single transfer to be more convenient.

If the organisation *needs* a C compiler and no free compiler is
available, it will buy one. If it isn't prepared to buy one,
presumably it doesn't need one.

It doesn't *need* a C compiler. That's the problem. While
ever there are organizations who don't *need* one, there
will be programmers who don't *have* one, unless there is
one freely available.

So perfectly good C code needs to be rewritten for no
reason other than it's too expensive to justify the cost
of a commercial compiler that can compile it.

Hence the effort to ensure a lingua franca exists, meaning
creating a free C compiler in places where one doesn't
exist.

BFN. Paul.

 

[James Kuyper]

Bart van Ingen Schenau wrote:
... snip ...

Not so. Nothing prevents someone producing a routine that puts a
character on a screen and advances the screen location. This is a
sufficient interface for HelloWorld. Happens every day in the
embedded world.

Nothing? Not even the complete absence of anything even remotely
resembling a screen, to display the character on? This is, I believe, a
typical issue for the kinds of platforms Bart was referring to.