C90 penetration

[James Kuyper]

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.

You're stating these things as if they were general rules. They are not.
They're peculiarities of your particular workplace - peculiarities that
it might share with some other workplaces, but certainly not with all
workplaces.

The time it would take me to do the task you describe would cost my
company a lot more money (and gain them a lot less value) than buying a
C compiler. If that's not the case for you and your company, that
implies that you're either very under-paid, or a much better assembler
programmer than I am. That last criterion isn't hard to meet - I've
programmed in three different assembly languages, but I spent a combined
total of no more than about three months programming in those languages,
and it was more than a decade ago.

....

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.

If they don't need it, how can not having it be a problem?

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.

I think there's a good chance that whoever made that decision forgot to
include the cost of the time required to re-write the code when deciding
which choice was less expensive. Alternatively, they may have made the
decision thinking of this as a one-time thing, when in fact the need to
do this is likely to come up over and over again: the total cost of all
the time spent doing all of the rewrites that will eventually be needed
must be taken into consideration.

If that cost was correctly estimated, and it still came out as the
less-expensive option, then it was the right decision, and I don't see
any problem with it.

 

[Richard Bos]

Why is that necessary? Using the current standards
every machine code can be generated directly from C.

Proof, please?

Richard

 

[kerravon]

You're stating these things as if they were general rules. They are not.

Right, they are, at least in my experience, which is NOT with
one isolated company.

They're peculiarities of your particular workplace - peculiarities that
it might share with some other workplaces, but certainly not with all
workplaces.

I didn't say all. They are general rules.

The time it would take me to do the task you describe would cost my
company a lot more money (and gain them a lot less value) than buying a
C compiler.

That's not true for the first C utility if it's just a hexdump.

And especially not when you consider all the paperwork that
needs to go through to get a purchase request in. It's not
easy to justify the purchase. And your boss may well not want
to stick his neck out asking for a C compiler.

And even if you think there's more utilities you may need to
port, you can't necessarily predict that, because you haven't
encountered them yet.

If that's not the case for you and your company, that
implies that you're either very under-paid, or a much better assembler
programmer than I am.

No, it implies that bureaucracy doesn't work according to
strict logic. At my place of employment, 3 contractors have
left of their own accord and not be replaced. Do you think we
could use the cost savings from that to increase our mail
space quota so that we don't have to waste our lives
archiving mail all the time etc etc? Not on your life.

For whatever reason, you can employ staff fairly easily,
but not get tools very easily. I did a short stint as an
English teacher as a break from programming, and the
place I worked at didn't even have enough tape decks.
TAPES. In 2007! People used to have to fight over TAPE
RECORDERS. In the short time I was there I converted the
tapes to CDs and the CDs into MP3s and bought my own
MP3 boombox to use in class.

They didn't mind me doing all that, but they still
wouldn't buy a US$70 boombox for each teacher.

If they don't need it, how can not having it be a problem?

Reduced productivity, and the world as a whole has just
paid for the wheel to be reinvented. A tragic waste of
limited resources. All costs passed on to the consumer,
of course. More sad people on TV talking about how they
just sold the last straps holding up their barrel.

I think there's a good chance that whoever made that decision forgot to
include the cost of the time required to re-write the code when deciding
which choice was less expensive. Alternatively, they may have made the
decision thinking of this as a one-time thing, when in fact the need to
do this is likely to come up over and over again: the total cost of all
the time spent doing all of the rewrites that will eventually be needed
must be taken into consideration.

You're making an underlying assumption in there that someone
even makes a "decision". Do you really think someone in the
company did some technical analysis and decided that staff
were good value for money so they can be hired at will, but
mail space is scarce and must be strictly limited? People
inherit procedure. Even my own exact programming area is
way too big to be fully understand and we have to rely on
inherited procedures hoping that our predecessors have
given the correct procedure to the operators.

Sometimes we will get a question from ops saying "are we
still meant to ignore this error message as per
instructions?". I just have to say yes. It may take a
man-week to reverse-engineer it, just to come up with "yes",
and that would necessarily be time taken away from
definite production problems that people are waiting
for fixes for.

If that cost was correctly estimated, and it still came out as the
less-expensive option, then it was the right decision, and I don't see
any problem with it.- Hide quoted text -

Well, I see a problem with how things often work in reality,
and that's the problem I'm trying to solve.

BFN. Paul.

 

[James Kuyper]

James Kuyper said:


Well, you don't need a screen to display characters if you've got a
printing device or a network connection or a filesystem or
whatever...

That's what I intended to cover by the phrase "even remotely resembling".

... but of course none of these are required to be present
either, so I do take your point.


On the contrary, it's not even remotely an issue for such platforms.
You know why? Because if it /were/ an issue, they'd fix it - by
adding a display device. The absence of a display device is an
indication that no display device is necessary. We may deduce that
the absence of a display device indicates that the platform was
never intended to be used for running "Hello World".

What I meant by saying that it was an issue, is that this is one common
reason for the absence of the <stdio.h> portion of the standard library.
I didn't mean that it was necessarily a problem.

However, it could still be a problem: the fact that a platform was never
intended to support I/O doesn't eliminate the possibility that you'll
find yourself in a situation where you wished that it did have that
capability. I've routinely found myself in situations where I wished a
device had a capability that it's designer never intended it to have.

 

[James Kuyper]

Right, they are, at least in my experience, which is NOT with
one isolated company.


I didn't say all. They are general rules.

I doubt it. They're not true of any of the several place where I've
worked. I'm not saying that there are no such workplaces, just that you
may be overestimating how common they are. They sound like companies
reacting badly to severe financial stress; there's certainly a lot of
companies like that, particularly in the current financial crisis.
However, there's also companies which handle financial stress in a more
rational manner, and other companies that aren't under serious financial
stress at all.

No, it implies that bureaucracy doesn't work according to
strict logic.

It never does. The bureaucracy you work with appears to suffer from
problems different from those of the one that I work with, but they all
have problems.

Reduced productivity, and the world as a whole has just
paid for the wheel to be reinvented. ...

You said that they didn't need it. If it would improve productivity, and
they still don't need it, this implies that they don't need to improve
productivity.

... A tragic waste of
limited resources. ...

If resources are limited, then they do need it - to keep resource usage
more efficient. Unless, of course ...

... All costs passed on to the consumer,

If a company can pass increased costs on to the consumer without a net
reduction in their profits, then it doesn't make sense for it to worry
about those costs.

The more typical position is that a company can only pass on some
fraction of its increased costs, with the rest of those costs causing a
reduction in net profits. When that is the case, the company does need
to cut costs, and that means it should consider the possibility that it
does in fact need a C compiler, in the sense that the compiler might
save them more money in the long run than it would cost to buy it.

You're making an underlying assumption in there that someone
even makes a "decision". Do you really think someone in the
company did some technical analysis and decided that staff
were good value for money so they can be hired at will, but
mail space is scarce and must be strictly limited?

Someone made that decision. They might not have made it explicitly, but
at the very least they made the decision by default when they failed to
decide explicitly.

That someone might have failed to do a sufficiently detailed analysis to
justify the decision would not surprise me; that was, in fact, the point
of my criticism. However, that a detailed analysis was not done is not,
in itself, necessarily a mistake. A detailed analysis is needed only
when the issues are important and the options are sufficiently similar
that it takes a detailed analysis to determine which one is best. It's
often the case that a decision doesn't really matter, or that there's on
option that's so clearly better than any of the others that detailed
analysis is not required.

 

[kerravon]

More likely, he'll be told to stop wasting his and the IT manager's
time. If he doesn't know how to get a hexdump by now without
writing a new C program to do it, there's something wrong.

The average programmer probably doesn't know the arcane
IDCAMS PRINT DUMP. On the Unix I use, "od -x" is crap.
Regardless, I have my own utility, which I am happy with,
written in portable C, and I can run it on any alien
environment I encounter. E.g. I only recently started
using CMS. I've done many hexdumps. If there's a native
hexdump, I don't know it.

And a hexdump is just one example anyway. What's the
native CMS call to calculate a CRC-32 of a block of
memory?

Given that even expensive C compilers are so cheap compared to any
reasonably-sized organisation's IT budget, if the organisation as a
whole doesn't have a C compiler it can only be because IT
management has decided it doesn't need one, presumably because it
can get by with the stuff it already has.

Of course it can get by. As it has been for many years.
Which is exactly what the bottleneck for C90 as a
lingua franca is, as far as I can tell.

It's common sense to use
what you've got if it will do the job and save you spending money
on something you don't currently have.

It will do the job. It can be written in assembler, just like
everyone else does. The people who are doing the programming
don't necessarily care. They get paid regardless. Who is the
person who is going to point out that the company would be
better off with a C compiler? Some of these things aren't
that easy to even measure anyway.

That sounds more like broken than working, but smuggling a C
compiler onto the mainframe is not the right fix.

Can you name one organization with nothing broken in it?
I'll go to them to get bug-free code too - a one-stop shop.
I'd love to see the women there too.

And that's not necessarily "smuggling" anyway. So long as
it's free so that no paperwork is involved, it's no different
from writing it yourself, at least if it's in source form.
It depends on your boss. I got permission to use CVS in
development the same way. PVCS is the official thing to
use, but it's only used for final submission to production
rather than during development.

And there's very few people or organizations I have encountered
that know what a 3-way diff is, despite being one of the major
milestones of computer science (in my opinion). I see enormous
lost productivity because of this. I can remember explaining
project branches to one manager-type person who was about to
implement this new concept of "module ownership" (one person
would make all the changes for all the different projects to
a particular source file). I explained that CVS would
automatically do the merging if it was set up like that.

His "decision" was based on "do you really think we would be
going to all this effort if it was possible to do it
automatically?". That's what he literally said to me.

I left that company and returned a couple of years later and
asked whether the scheme had been implemented. It had! And I
was told the conclusion was "and we must never do this again".

Something like that is very difficult to justify to my boss
as well, as I need to spend time on the CVS admin side, so
that we don't have source control problems. Since so few
people understand the 3-way diff, they don't see why I need
to spend an hour stuffing around with the source code when
it's already been delivered to us and sitting there ready
to use.

It depends on the boss whether they trust you enough to let
you do it the non-standard way which they don't even
understand. Given sufficient time I will then be in a
position to say "when was the last time we had a source
control problem from our end?". Similar to "how many
people are now using info-zip now that we've got a
C compiler"?

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.

There is a way to initiate the transfer in software. I ***may***
even have code to do it, although that was a few machines ago and
it could easily have got lost. I'll look if I find time.

I don't have a problem with the current zip method. I've
stopped transferring files to that site.

So... fix it?

I would have to get familiar with the source code to do
that. Last time I started down that route with newlib on
Cygwin I didn't get very far. It pollutes the namespace
with Unix nonsense and there was no easy way to reverse
that out, and the powers that be didn't see anything
particulary wrong with a non-conforming C compiler.

So much for a lingua franca!

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.

Um, quite. I remember having to cut code to translate [ and ] into
the characters that, after conversion, would represent the EBCDIC
characters that the C compiler insisted upon for [ and ] - the

The text mode transfers aren't even getting far enough
to hit that problem.

alternative was trigraphs (which you'd think was unthinkable,
except that I have actually worked on a code base that was littered
with the darn things). Such translation is a nuisance, but /only/ a
nuisance.

So is writing code in assembler instead of C.

It's easy enough to arrange to do them all in one operation
/without/ using zip.

The filenames need to be changed on the CMS system too.
My unzip program (written in C) accounts for that.

Then there's no problem.

Yes there is.

A lack of problem is normally only a problem for teachers.

I'm only relating first-hand experience of having to write
things unproductively in assembler.

But if they don't need one, why have one?

Not everything is done on a "need" basis. Why do you
have a colour TV when you can get by with bongo drums?

Or you just do your processing locally and transfer it up, as I've
suggested. It's not difficult.

That's just one of many problems I would normally solve
with a C program. How do I traverse MVS control blocks
locally?

Please don't misunderstand me - I'm not averse to the idea of a free
compiler for mainframes. But in my experience the kind of place
that won't pay for what it considers to be non-strategic software
tools is also the kind of place that won't allow programmers to
upload FOSS onto the mainframe anyway!

There's no blanket rule like that. Even if not all organizations
will be covered with a free C compiler, some can be and have been.
And at least the problem is now down to politics. The barrier of
financial cost and red tape for purchase orders and support
personnel have been eliminated, as people can upload the
required stuff to their private datasets, just as if they had
written it themselves.

BFN. Paul.

 

[kerravon]

I doubt it. They're not true of any of the several place where I've
worked. I'm not saying that there are no such workplaces, just that you
may be overestimating how common they are.

Well I've only worked for American, British and Australian
companies.

They sound like companies
reacting badly to severe financial stress;

No, they were all like that, regardless of economic conditions.

You said that they didn't need it. If it would improve productivity, and
they still don't need it, this implies that they don't need to improve
productivity.

We seem to have different definitions of "need". The productivity
of one programmer who needs to write a utility as one part of his
job will not make or break the company. Hence I wouldn't use the
word "need". But in my opinion, the correct thing to do is reuse
existing code, precisely BECAUSE the utility in question is not
critical to the business.

If resources are limited, then they do need it - to keep resource usage
more efficient. Unless, of course ...

It would be nice if people saw the long-term need to divert
resources away from Saddam's palaces and thugs and into
security forces that protect human rights.

But that's not how the world works, including a random 50%
of this list (and it's totally unpredictable which ones
are in which group). Only 1 in 12 (or similar) change from
their parents religion too. Quite frankly, we are lucky
that science gets as much of a say as it does already.
Watch Blackadder 1 where he gets burnt at the stake for
being a witch after all the "evidence" presented in court.

If a company can pass increased costs on to the consumer without a net
reduction in their profits, then it doesn't make sense for it to worry
about those costs.

The lost resources are unmeasurable in how much is gouged
from the customer any particular year.

The more typical position is that a company can only pass on some
fraction of its increased costs, with the rest of those costs causing a
reduction in net profits. When that is the case, the company does need
to cut costs, and that means it should consider the possibility that it
does in fact need a C compiler, in the sense that the compiler might
save them more money in the long run than it would cost to buy it.

There you go again using logic in an illogical world!

Someone made that decision. They might not have made it explicitly, but
at the very least they made the decision by default when they failed to
decide explicitly.

That someone might have failed to do a sufficiently detailed analysis to
justify the decision would not surprise me; that was, in fact, the point
of my criticism. However, that a detailed analysis was not done is not,
in itself, necessarily a mistake. A detailed analysis is needed only
when the issues are important and the options are sufficiently similar
that it takes a detailed analysis to determine which one is best. It's
often the case that a decision doesn't really matter, or that there's on
option that's so clearly better than any of the others that detailed
analysis is not required.

Right. A single programmer battling with assembler or his mailbox
or source control isn't significant enough to come to anyone's
attention (the source control sometimes might, but they don't
know what to do about it other than to chastise the programmer
who also doesn't know what to do about the normal human error).

So resources are lost, for the want of a free C compiler. Or
because "diff3" isn't taught at Uni. Or because of some dogma
or another.

BFN. Paul.

 

[Ben Bacarisse]

http://bytecraft.com/C_versus_Assembly

This document would be more persuasive if it listed the full results
or at least included examples where it is not so obvious what C to
use. For example, what C did you use to get BRSET (branch if a
numbered bit is set at some memory location) or ROLA (rotate left
through carry)?

I am not disputing the result, just the persuasiveness of the
document.

Also, it has to be said the RS08 is very limited. Can you get the
same effect on the more complex models in the range that have things
like NSA (nibble swap accumulator) and DAA (decimal adjust
accumulator)? Access to these sort of operations is exactly the
reason some people feel they must write in assembler.

Of course there is a sort of null method where you provide "single
op-code" function that get inlined but that would, presumably, not be
in the spirit of the exercise.

 

[Walter Banks]

Proof, please?

Richard

http://bytecraft.com/C_versus_Assembly

Regards,

 

[Ben Bacarisse]

Bit vars use C99 _Bool data type

We have use a int anded with mask for single bit selection as well

0040 0000 _Bool BitVar;
// Bit operations

0246 11 40 BCLR 0,$40 BitVar =
0; // BCLR 0,opr8a
0248 10 40 BSET 0,$40 BitVar =
1; // BSET 0,opr8a

024A 01 40 01 BRCLR 0,$40,$024E if (BitVar != 0)
NOP(); // BRCLR 0,opr8a,rel
024D AC NOP
024E 00 40 02 BRSET 0,$40,$0253 if (BitVar == 0) goto
rel;
0251 30 9E BRA $01F1

0253 00 40 01 BRSET 0,$40,$0257 if (BitVar == 0)
NOP(); // BRSET 0,opr8a,rel
0256 AC NOP
0257 01 40 02 BRCLR 0,$40,$025C if (BitVar == 1) goto
rel;
025A 30 95 BRA $01F1

ROLA (rotate left through carry)

01DE 49 ROLA AC = CC.C + (AC <<
1); // ROLA
01DF 46 RORA AC = (CC.C << 7)+(AC >>
1); // RORA

Ah, I see. The carry bit is exposed at the C level through a variable
(presumably a bit-field). Very impressive.

NSA was a shift mask and or if I remember correctly something like
the RORA above. DAA has an equivalent logical operation.

I wonder if the kind of loop that a C programmer would write when
doing BCD would actually trigger its generation. Do you happen to
know?

It would be very impressive if natural-looking BCD C code compiled to
pretty much the same as an assembler programmer would write. (I can't
hazard a guess what that would be because it has been too long since I
wrote even one line of assembler.)

For every processor we have implemented since 18037 was supported
we have created similar tests. The test in every case implements every
instruction. The eTPU for example on automotive engine controllers.


True, although there are some opcodes are usually implemented
by compilers as intrinsics. Most of our compiler's have intrinsics
for NOP for example. Many have intrinsics for interrupt
enable / disable.

I assumed that some would have to be provided that way. For one
thing, when some extra property of the opcode is important (for
example the atomicity of test-and-set or compare-and-swap) a programmer
would want to write that explicitly rather than rely on the fact that
some specific sequence of C happens to generate that instruction.

 

[Richard Bos]

The GCC code is full of Unix nonsense. They even open files
with open() instead of fopen(), for no reason that I can
think of for what is after all a text-processing program!

Oh, I can think of a reason, all right. Or do you believe that Microsoft
are the only ones to use embrace-and-extend?

Richard

 

[Richard Bos]

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.

So, no for loops beyond the simplest possible ones, no printf() calls
(and indeed no way to print numbers except by computing each digit
yourself - interesting for floating point), and no expressions with more
than one operator. Must make for very legible code...

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

I've never had to use assembler in application code yet. If I ever do,
I'd rather use assembler than write broken C code.

Richard

 

[Richard Bos]

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

I like this typo.

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.

_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.

Richard

 

[Walter Banks]

This document would be more persuasive if it listed the full results
or at least included examples where it is not so obvious what C to
use. For example, what C did you use to get BRSET (branch if a
numbered bit is set at some memory location) or ROLA (rotate left
through carry)?

Bit vars use C99 _Bool data type

We have use a int anded with mask for single bit selection as well

0040 0000 _Bool BitVar;
// Bit operations

0246 11 40 BCLR 0,$40 BitVar =
0; // BCLR 0,opr8a
0248 10 40 BSET 0,$40 BitVar =
1; // BSET 0,opr8a

024A 01 40 01 BRCLR 0,$40,$024E if (BitVar != 0)
NOP(); // BRCLR 0,opr8a,rel
024D AC NOP
024E 00 40 02 BRSET 0,$40,$0253 if (BitVar == 0) goto
rel;
0251 30 9E BRA $01F1

0253 00 40 01 BRSET 0,$40,$0257 if (BitVar == 0)
NOP(); // BRSET 0,opr8a,rel
0256 AC NOP
0257 01 40 02 BRCLR 0,$40,$025C if (BitVar == 1) goto
rel;
025A 30 95 BRA $01F1

ROLA (rotate left through carry)
// AC ops

01D8 4F CLRA AC =
0; // CLRA
01D9 43 COMA AC =
~AC; // COMA
01DA 4C INCA
AC++; // INCA
01DB 4A DECA
AC--; // DECA
01DC 48 LSLA AC <<=
1; // LSLA
01DD 44 LSRA AC >>=
1; // LSRA
01DE 49 ROLA AC = CC.C + (AC <<
1); // ROLA
01DF 46 RORA AC = (CC.C << 7)+(AC >>
1); // RORA

I am not disputing the result, just the persuasiveness of the
document.

Also, it has to be said the RS08 is very limited. Can you get the
same effect on the more complex models in the range that have things
like NSA (nibble swap accumulator) and DAA (decimal adjust
accumulator)? Access to these sort of operations is exactly the
reason some people feel they must write in assembler.

NSA was a shift mask and or if I remember correctly something like
the RORA above. DAA has an equivalent logical operation.

For every processor we have implemented since 18037 was supported
we have created similar tests. The test in every case implements every
instruction. The eTPU for example on automotive engine controllers.

Of course there is a sort of null method where you provide "single
op-code" function that get inlined but that would, presumably, not be
in the spirit of the exercise.

True, although there are some opcodes are usually implemented
by compilers as intrinsics. Most of our compiler's have intrinsics
for NOP for example. Many have intrinsics for interrupt
enable / disable.

What really becomes interesting is running a Microchip PIC
instruction test on a RS08 or eTPU. In most cases some processor
specific registers need to be declared as an int or char. (eTPU has
a 24 bit data path)

This is a good exercise on many levels. It validates processor
instruction
set usage and triggers many application optimizations that conventional
optimization tests miss.(Because these tests are so processor specific)


Regards,

 

[Stefan Ram]

This is a test suite to demonstrate that
any asm "could" be written in C

What's the C code to test the processor's
carry or overflow flag?

 

[Walter Banks]

So, no for loops beyond the simplest possible ones, no printf() calls
(and indeed no way to print numbers except by computing each digit
yourself - interesting for floating point), and no expressions with more
than one operator. Must make for very legible code...

I was describing a some test code not compiler limits. This is
a test suite to demonstrate that any asm "could" be written in C
in the same or less code. There is no size / performance
advantage to assembler.

Regards,

 

[Walter Banks]

I wonder if the kind of loop that a C programmer would write when
doing BCD would actually trigger its generation. Do you happen to
know?

It would be very impressive if natural-looking BCD C code compiled to
pretty much the same as an assembler programmer would write. (I can't
hazard a guess what that would be because it has been too long since I
wrote even one line of assembler.)

The biggest win is improved overall code generation. This test
tends to get obscure instructions generated by the compiler in
unexpected places. Inline asm tends to break data optimizations
(break in the sense that data and control flow information is
disrupted) This approach to low level code has unexpected
results.

A C compiler makes code generation choices each time it compiles
a source. As an assembler program is developed it goes through
changes the are often implemented as sub optimal (in the global
application view) implementation. Most instruction sets have
redundancy and most assembly language programmers tend to
use instruction subsets.

When whole asm applications are translated to C the compiler
has a whole application view often resulting is significantly less
cycles, less code and less RAM.

Thanks for the comments

w..

..

 

[Stefan Ram]

025E 35 02 BCS $0262 if (CC.C == 0) goto relbra; // BCC

OK, but this semantics (BCC/BCS) of this code
(»if(CC.C==0)goto relbra;«) is not given by ISO/IEC 9899:1999 (E),
so this can be taken to be another language that is an
extension of C. It shares the syntax, but there are special
semantics for some special identifiers. (I do not claim that
something was wrong with this.)

 

[Walter Banks]

What's the C code to test the processor's
carry or overflow flag?

025E 35 02 BCS $0262 if (CC.C == 0) goto relbra; // BCC

0269 35 01 BCS $026C if (CC.C == 0) NOP();
026B AC NOP

Regards,

 

[Walter Banks]

OK, but this semantics (BCC/BCS) of this code
(»if(CC.C==0)goto relbra;«) is not given by ISO/IEC 9899:1999 (E),
so this can be taken to be another language that is an
extension of C. It shares the syntax, but there are special
semantics for some special identifiers. (I do not claim that
something was wrong with this.)

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

This ISO TR covers a number of topics,
- Fixed point math Accum and Fract data types
- Access to processor specific registers
- Named address space to deal with processors with multiple address
space
- User defined address space to support variable access and support for
memory on I2C buses for example

There are other ISO C TR's to support Decimal floating point and C
Library extensions

Regards,