Making Fatal Hidden Assumptions

Got me there. Freestanding only, with maybe 16 bytes of RAM and 256 words of ROM - no 'malloc()' here, and 'printf()' can be problematic.

A freestanding C implementation does, however, still have a C compiler. I'm curious which processors Andrew Reilly claims "will never have a C compiler", and why he makes that claim.

mlp

This reminds me of C--:

The "decent-sized" library for small embedded systems is easier to meet than you may think. Be sure to look up "freestanding implementation" in the library section of the C standard.

Following the only truly formal definition, "C compilers, just not conforming ones" don't of course exist any more actually than there are cars on the highway with "wheels, just not round ones."

[...]

Long long is, for many such compilers, still a non-issue, because they never claimed to have implemented C99. C89==C is still a widely accepted assumption.

Some people would probably also not shy away from claiming there are

18-wheeler trucks built with only two wheels. Even all things considered, such people are blatantly wrong (because they've been lied to by, or are, marketroids). There's no excuse for violating a strict requirement of the standard just to match users' likely interpretation of one of the helpful suggestions, like "int should be the natural integer type of the target CPU".

The rule of thumb should be one of practicality. Try hard to fit as much of the language as you can on the CPU, but stay reasonable. I.e. all features that lie in the intersection between the standard's requirements and the platform's feature set, should be implemented strictly by the C standard. For the rest, stay as close to the standard as you can bear. And above all, *document* all such deviations prominently.

In case of doubt, do what every clever politician would do: refuse to decide, so the users can unload the decision and the responsibility on their own shoulders. Implement both a "standard as standard can" mode, and a "as much standard as we think makes sense" mode. E.g. on

8-bit or smaller CPUs C's default integer promotion rules can turn into a serious liability; offering a flag to turn them on or off makes sense.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

I assume Dr. Reilly's referring to various DSP devices. These often have features such as saturating arithmetic and bit-reversed addressing.

Regards, Allan

Overflow's undefined, so what's wrong here?

I don't know what that is, so I have no idea how it would affect the ability for there to be a conforming implementation

For many small embedded applications the C library is unnecessary.

Ian

I don't think anyone will ever write a C Compiler for the Atmel MARC4 [

].

--
Guy Macon

The trick is that there is no "the" C library. There two vastly different C libraries. The one required for freestanding implementations is *much* smaller than the full-featured one required for hosted implmentations. Even a rather small embedded C system will want to have the freestanding implementation. It's small enough that it won't usually be a problem to implement and use, either.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

I think that a useful "universal assembler" would be something that had the basic set of operators and types, all of which were well defined for a particular machine model (flat data memory map, 2's compliment arithmetic, etc.) It could have expressions, as long as the operator precedence was rigorous enough so that you could absolutely know what the order of evaluation would be, at coding time.

The two or three most painful things about assembly language programming are register allocation and making up control-flow symbol names (in assemblers that don't already have nice structured control flow macros/pseudo-ops. Both of these can be included in a "universal assembler", if you forgo some pure control for convenience: conventional control structures, subroutine calls that follow common conventions. The machine instruction sets of Java's JVM and C#'s CLR (?) avoid the register name issue by being stack-based (and muck up the memory model by being object-centric). Tao's VM is more nearly a plain 32-bit RISC model, but with an infinite number of registers, which are managed by the "assembler". (The third painful thing is instruction scheduling, in super-scalar or VLIW machines of various sorts. That would probably want to be subsumed by the language "compiler" too.)

A data model, a set of operators, control flow, a syntax for building abstractions and domain-specific sub-languages. That could almost be C right there, except that there are too many holes in the data model and operator function, both to support old/strange hardware, and to allow/support compiler optimization transformations. Java has tightened up the model, but it's not a model of a "bare processor", it's a model of an "object machine". I'd like the same kind of low-level language definition, but with objects only built using the language's meta-programming/macro features, rather than being the only way to do things.

Just dreaming...

Cheers,

--
Andrew

I'm thinking mainly of deeply embedded DSP processors, like those of the TI TAS3000 family, or Analog Devices Sigma DSPs, or any of several similar-scale engines from several Japanese manufacturers.

Small memory, sure. Strange word lengths (not really that much of a problem for C, admittedly). Some of these things don't have pointers in the usual sense, let alone subroutine call stacks. Their arithmetic usually doesn't match C's (integer only, usually with saturation on overflow, freqently with different word lengths for data, coefficient and result.

Apart from the reasons that I mentioned, the biggest one is simply utility and man-power. No-one is building C compilers for these things because no-one could or would use one if it existed: the hardware is tuned to do a particular class of (fairly simple) thing, and that's easy enough to code up in assembler. Easier than figuring out how to write a C compiler for it, anyway.

Cheers,

--
Andrew

Off topic? Yes. But, I it bothers me when we confuse the language with the supporting libraries.

-- Michael N. Moran (h) 770 516 7918

5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144

"So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

The CDC 6400 and 6600 used "complement recomplement arithmetic." The only way to get -0 as the result of integer arithmetic was to start with

-0, i.e. (-0)+(-0) = -0 and (-0)-(+0) = -0.

The normal way to copy a B-register was to write, e.g. SB6, B5 (IIRC) which generated the same machine opcode as SB6, B5+B0. (B0 was an always-zero register.) Hence SB6, B5 was not guaranteed to copy B5 exactly! Instead SB6, B5-B0 should be coded.

Since there were fast tests for negative and zero, using both +0 and -0 as flags for testing was a micro-optimization sometimes useful for speed.

James Dow Allen

The "library" required for a freestanding implementation is only a collection of macros and types, not functions, correct? As such, I would say the "size" of it is zero, as far as code space required on the target.

--
John W. Temples, III

Basically, yes. It's a library only in the sense of "a collection of things you may want to use". It's not a collection of object modules. Most implementations will still provide some library functions going beyond the pure freestanding environment, though. is basically always there, closely followed by .

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 2006-03-09, James Dow Allen wrote: > David Holland wrote: >> On 2006-03-07, James Dow Allen wrote: >>> [...] but I'm sincerely curious whether anyone knows of an *actual* >>> environment where p == s will ever be false after (p = s-1; p++). >>

Have you tried bounds-checking gcc?

I don't think I've ever myself seen a compiler that targeted 286 protected mode. Maybe some of the early DOS-extender compilers did, before everyone switched to 386+. If you can find one and set it to generate code for some kind of "huge" memory model (supporting individual objects more than 64K in size) I'd expect it to trap if you picked a suitable location for `s' to point to.

That assumes you can find a 286 to run it on, too.

Otherwise, I don't know of any, but I'm hardly an expert on strange platforms.

(Note: Coherent was a 286 protected mode platform, but it only supported the "small" memory model... and it had a K&R-only compiler, so it's not a viable example.)

--
   - David A. Holland
     (the above address works if unscrambled but isn't checked often)

There is no 'requirement' for any library in a free standing system.

No it won't if it does not need it.

But often it is not small enough. Why put in something you do not need?

Ian

As long as we're talking about C, they are part of the same Standard. You can get a freestanding implementation which is allowed not to implement much of the Standard, but that doesn't make those parts any less C.

Richard

If the saturation also occurs for unsigned integers, you're going to have a pain of a time implementing C's wraparound-on-unsigned-overflow behaviour.

Richard

(First hit)

Bit reversed addressing is just another addressing mode that's simple to access from assembly language. Do you think that this could be generated by a C compiler?

Bit reversed addressing is used in the calculation of an FFT (and almost nowhere else).

Regards, Allan