C90 penetration

[kerravon]

_If_ he has the authority to install programs. It's quite possible that
he doesn't have that authority, and given the tasks that some of these
systems get used for, there might well be very good reason for him not
to have it.

The C compiler doesn't require any special systems programming
authority to install. It can be run from your personal datasets.

So there's very little difference between a programmer writing
his own assembler code or uploading some existing assembler
code. There's a very good chance that his boss won't give a
damn about that.

BFN. Paul.

 

[Phil Carmody]

http://bytecraft.com/C_versus_Assembly

On the first page, you indicate that you rely on a #pragma.
Therefore you're not talking about C, you're talking about
only some implementations of C that have particular extensions.

And how does the ``(void)AC - page0;'' on page 2 work?

Phil

 

[Walter Banks]

On the first page, you indicate that you rely on a #pragma.
Therefore you're not talking about C, you're talking about
only some implementations of C that have particular extensions.

And how does the ``(void)AC - page0;'' on page 2 work?

This is C99 plus ISO/IEC 18037. Programming languages - C - Extensions
to support embedded processors

The expression is cast to void. However the side effects of setting the
condition codes remain.


Regards,

 

[Keith Thompson]

This is C99 plus ISO/IEC 18037. Programming languages - C - Extensions
to support embedded processors

The expression is cast to void. However the side effects of setting the
condition codes remain.

Surely that should be
(void)(AC - page0);
Otherwise you have a "-" operator whose left operand is of type void.
That's a constraint violation in standard C; I assume ISO/IEC 18037
doesn't change that.

 

[Thad Smith]

For more than a decade most serious commercial compilers
have not needed assembler for speed critical code.

When you say, compilers have not needed assembler for speed critical
code, I assume you mean that those compilers eliminate need of using
assembly for the application programmer, instead of a requirement for
writing the compiler.

Consider these application timing constraints:
1. A code segment executes under 100 us.
2. A code segment executes in exactly 12 us.

The first constraint can be verified by running test code and timing.
However, if a compiler option is changed, will it still be valid? If
adding additional variables causes time-critical variables to be divided
among more than one page (think PICs), will the timing be valid? If the
compiler is updated or even replaced with a version for another vendor,
will the timing stay valid? One way to accomodate variations is to
retest timing after any possible or suspect changes. These tests
usually cannot be easily automated.

The second constraint is even more critical. While C code can be
tweaked, in a lot of cases, to achieve the exact timing requirement, it
is subject to the same sources of variation.

While target-specific C can to be used to achieve critical timing
requirements in many cases, it takes vigilance to assure continued
compliance with system changes.

In contrast, assembly code performance isn't normally subject to the
variations stated above.

Don't misunderstand -- I use C whenever I think it is feasible, but
there is still a valid reason for using assembly code.

 

[Walter Banks]

Surely that should be
(void)(AC - page0);
Otherwise you have a "-" operator whose left operand is of type void.
That's a constraint violation in standard C; I assume ISO/IEC 18037
doesn't change that.

You are absolutely right the code and the paper are
different. The code has (..) around the expression.
Not enough coffee

w..

 

[Walter Banks]

When you say, compilers have not needed assembler for speed critical
code, I assume you mean that those compilers eliminate need of using
assembly for the application programmer, instead of a requirement for
writing the compiler.

Consider these application timing constraints:
1. A code segment executes under 100 us.
2. A code segment executes in exactly 12 us.

The first constraint can be verified by running test code and timing.
However, if a compiler option is changed, will it still be valid? If
adding additional variables causes time-critical variables to be divided
among more than one page (think PICs), will the timing be valid? If the
compiler is updated or even replaced with a version for another vendor,
will the timing stay valid? One way to accomodate variations is to
retest timing after any possible or suspect changes. These tests
usually cannot be easily automated.

The second constraint is even more critical. While C code can be
tweaked, in a lot of cases, to achieve the exact timing requirement, it
is subject to the same sources of variation.

While target-specific C can to be used to achieve critical timing
requirements in many cases, it takes vigilance to assure continued
compliance with system changes.

In contrast, assembly code performance isn't normally subject to the
variations stated above.

Don't misunderstand -- I use C whenever I think it is feasible, but
there is still a valid reason for using assembly code.

Thad,

You have some good points.

I was being careful with my words. What this post addressed is that
resorting to assembly to overcome C compiler performance problems
has been passed.

C as a language does not syntactically have a way for describing
timing constraints which is your main point. We have looked at
exact timing constraints as a compiler extension. It isn't easy.

Exact timing is one of the few cases that asm might be needed.
The white paper elsewhere on this thread that looks at the C
test cases for the instruction set does not enforce instruction
timing, where possible it attempts to optimize the C source.
Translating a asm source almost always generates smaller faster
code.

The automotive industry got away from the need for exact timing
in most applications by extensive use of timers and precomputing
actions.

Regards,

 

[Richard Bos]

http://bytecraft.com/C_versus_Assembly

Myeah; and now using C, please?

That document has very little, if anything, to do with "the current
standards". Instead, it uses C _plus_ some extraneous standard which
specifically lets you write C as if it were assembler, making your point
trivially true in that C-plus-something-else language, but also
rendering it irrelevant to C as it is usually understood.

Besides, if you're going that far - why _not_ use the damn assembler,
already?

Richard

 

[Walter Banks]

Myeah; and now using C, please?

That document has very little, if anything, to do with "the current
standards". Instead, it uses C _plus_ some extraneous standard which
specifically lets you write C as if it were assembler, making your point
trivially true in that C-plus-something-else language, but also
rendering it irrelevant to C as it is usually understood.

Besides, if you're going that far - why _not_ use the damn assembler,
already?

"_plus_ some extraneous standard" ISO 18037 is heavily used in
automotive engine controllers, consumer electronics and cell
phones .

C as it is usually understood is very flexible implementation
capability. C99 + 18037 gives that capability. It offers flexible

why _not_ use the damn assembler, already?

C preserves the data and flow control information that is used by
the optimizer to generate code. Even the very low level C will
port with minimal effort between processors.

Regards,

 

[wolfgang.riedel52]

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. (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.)

AFAIR, LE, not necessaribly LE370, was a requirement to run any
program, that linked into another library or system service, written
in the same language or another. The original languages we
used were COBOL PL/1 and HLASM (Fortran used those other guys).
But with USS (Unix System Sevices) (first AFAIR in MVS/ESA 4.3 1993),
certified in 1995, there was a Posix runtime and a C standardlibrary.
(AFAIK MVS was the first Open Group certified Unix!)

The first native C-compiler for IBM mainframes is C/370 V1R1 for MVS
and VM and dates from Dec. 1989, the current for z/OS is z/OS
V1.10 XL C/C++, for VM XL C/C++ for z/VM V1.2.

GCC is a story after my mainframe time.
I think, it came with the porting of linux on system z and provided
a complete - but separated from the native - posix environment incl.
filesystems, syscalls etc.
There was some communicatation between those two, but I don't know
ways or rules (I know some on the OS400).
Of course, Linux/390 is something completely different, running
barebone or in anything.
As such programs written for it have access to it's environment.
(AFAIK gcc/390 is still maintained mainly by IBM people)

greetings
Wolfgang

 

[kerravon]

hand-me-down PC on my desk.  I had to provide the "C" compiler.  I did
so and beat the 10:1 performance improvement i promised quite handily
(almost 100:1 actual improvement).  The solution worked, but because
of weird constraints was not well received.  If i had known 20 years
ago what i know now i would have never gotten myself in that fix.

What have you learned now that would have helped avoid getting
into that fix?

I've spent the last 20 years trying to avoid fixes like that by
trying to get a free C compiler for MVS!

BFN. Paul.

 

[kerravon]

GCC is a story after my mainframe time.

It's a story still being written. You can join the action
if you want:

http://gccmvs.sourceforge.net

I think, it came with the porting of linux on system z and provided
a complete - but separated from the native - posix environment incl.
filesystems, syscalls etc.

z/Linux is ASCII.

There was some communicatation between those two, but I don't know
ways or rules (I know some on the OS400).
Of course, Linux/390 is something completely different, running
barebone or in anything.
As such programs written for it have access to it's environment.
(AFAIK gcc/390 is still maintained mainly by IBM people)

And ASCII.

Real mainframe operating systems run EBCDIC, and the above
is the best native MVS compiler available.

BTW, you're right on about MVS amazingly qualifying for a
Posix environment early on (although it's a bit of a stretch
to call that MVS - it's just an overhead). However, like you
said, they came out with a C compiler around the same time
that the standard was finalized. And that was always a
decent product. IBM did have a program offering before that
though. Whitesmith's or something. The place I worked at
got both the program offering and then the first version
of C/370.

BFN. Paul.

 

[JosephKK]

What have you learned now that would have helped avoid getting
into that fix?

I've spent the last 20 years trying to avoid fixes like that by
trying to get a free C compiler for MVS!

BFN. Paul.

A host of things, among them not badmouthing management quite so
publicly, learning how to finesse the system to get what is needed
without promising too much. And the challenge promise that succeeded
became part of my toolkit, however not all organizations are
responsive to that.
.

 

[Chris H]

In message <[email protected]

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

Such that a person would be in a position where they can't even
accept a 20-line C program and would need to recode the
functionality in assembler etc, because they can't justify buying
a C compiler to compile a 20-line program they are interested in.

If you include the eval versions of commercial compilers *every* target
has a free C compiler to some extent

 

[Richard Bos]

In message <[email protected]


If you include the eval versions of commercial compilers *every* target
has a free C compiler to some extent

Probably true at least to any reasonable approximation, but the question
was about free _C90_ compilers. I suspect there are some historical-but-
still-used-in-faraway-legacy-situations systems which only have K&R
compilers available.

Richard

 

[Chris H]

Probably true at least to any reasonable approximation, but the question
was about free _C90_ compilers. I suspect there are some historical-but-
still-used-in-faraway-legacy-situations systems which only have K&R
compilers available.

I doubt it. They will all be C90 You are talking systems over 20 years
old! BTW K&R2 == C90 so you are revering to K&R1

Are there any historical but still in use systems that require a K&R
compiler? I would think that any system out there will have a C90
compiler available.

 

[Chris H]

You better define in use. Someone will say it includes as a teaching
example of
a historic system and likely post about some machine that predates K&R.

Go on then, I will be fascinated

there must be one somewhere.

 

[Richard Bos]

I doubt it. They will all be C90 You are talking systems over 20 years
old! BTW K&R2 == C90 so you are revering to K&R1

No, I am _referring_ to K&R1. While I do think Brian Kernighan did a
sterling job with the book, I certainly don't go so far as to revere
him, or it.

Are there any historical but still in use systems that require a K&R
compiler?

I don't know, but I've seen odd heritage systems in use in several nooks
and crannies. I never checked what compiler they used, but I wouldn't
bet against there being a 25 year old system sitting quietly in its
corner and just doing its job _somewhere_.

Of course, for the vast majority of platforms, you are more than
correct. But the question wasn't about normal platforms, but,
contrariwise, about the exceptions.

Richard

 

[Chris H]

No, I am _referring_ to K&R1. While I do think Brian Kernighan did a
sterling job with the book, I certainly don't go so far as to revere
him, or it.

As the original book I thin it is OK to revere it (or refer to it) but
not for a book to learn C any more.

I don't know, but I've seen odd heritage systems in use in several nooks
and crannies. I never checked what compiler they used, but I wouldn't
bet against there being a 25 year old system sitting quietly in its
corner and just doing its job _somewhere_.

I know what you mean. I have seen a lot of old systems in corners but no
one had the SW for them so they got junked. But there must be somewhere
25 year old systems that are still running (other than embedded systems
because 25 years ago it was all ROM and you don't get a chance to
reprogram them... I suppose there might still be some systems with
EPROMS you could reprogram

Of course, for the vast majority of platforms, you are more than
correct. But the question wasn't about normal platforms, but,
contrariwise, about the exceptions.

I agree... so can anyone give any exceptions?

(I was expecting a whole list of them to come back