Making Fatal Hidden Assumptions

Right, which is why it's hard to imagine the library requirements being a burden on even the smallest target. But the standard doesn't define "library" as something to be linked to; it defines it with clause 7, which includes the above header files and their contents.

--
John W. Temples, III
Reply to
John Temples
Loading thread data ...

That seems inconsistent with the use of the term "library" in the sense usually/historically expected within the comp.arch.embedded, IMO. I suppose the standard framers and editors had to call it something, but confusion with people unschooled in the intracacies of the standard are to be expected, then.

--
Andrew
Reply to
Andrew Reilly

I posted a page-long description of what I concieve a universal assembler to be in a previous message in the thread. Perhaps it didn't get to your news server? Google has it here:

formatting link

The main properties that it would have, compared to a C (some other HLLs do have some of these properties) are:

a) Rigidly defined functionality, without "optimization", except for instruction scheduling, in support of VLIW or (some) superscaler cores. (Different ways of expressing a particular algorithm, which perform more or less efficiently on different architectures should be coded as such, and selected at compile/configuration time, or built using meta-programming techniques.) This is opposed to the HLL view which is something like: express the algorithm in a sufficiently abstract way and the compiler will figure out an efficient way to code it, perhaps. Yes, compilers are really quite good at that, now, but that's not really the point. This aspect is a bit like my suggestion in the linked post as being something a bit like the Java spec, but without objects. Tao's "Intent" VM is perhaps even closer. Not stack based. I would probably still be happy if limited common-subexpression-elimination (factoring) was allowed, to paper-over the array index vs pointer/cursor coding style vs architecture differences.

b) Very little or no "language" level support for control structures or calling conventions, but made-up-for with powerful compile-time meta-programming facilities, and a standard "macro" library that provides most of the expected facilities found in languages like C or Pascal. Much of what are now thought of as compiler implementation features would wind up in macro libraries. The advantage of this would be that code could be written to *rely* on specific transformation performance and existence, instead of just saying "hope that your compiler is clever enough to recognize this idiom", in the documentation. It would also make possible the sorts of small code factorizations that happen all the time in assembly language, but which single-value-return, unnested function call conventions in C make close to impossible. Or different coding styles, like threaded interpreters, reasonable without language extensions.

I imagine something like LLVM

formatting link
but with a powerful symbolic compile-time macro language on top (eg scheme...), an algepraic (infix) operator syntax, and an expression parser.

In the mean time, "C", not as defined by the standard, but as implemented in the half dozen or so compilers that I regularly use, is not so far from what I want, to make me put in the effort to build my universal assembler myself.

Cheers,

--
Andrew
Reply to
Andrew Reilly

This is a matter of terminology, but I'd say that code generation certainly is part of the compiler. If the compiler generates machine code directly that's certainly true. If it generates assembly language and invokes a separate assembler, I'd still say that the assembler is logically part of the compiler; both the front-end and the assembler are part of translation phase 7 as described in the C standard.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  
San Diego Supercomputer Center               
 Click to see the full signature
Reply to
Keith Thompson

I had forgotten about math. Another good reason to avoid C on small 8 bit micros.

Ian

Reply to
Ian Bell

I think we are talking at cross purposes here. By implementation I mean the code that ends up in the micro. You seem to be using it to mean the compiler.

Ian

Reply to
Ian Bell

I am confused again. The meaning of free standing implementation seems to me to be ambiguous. In previous posts I took it to mean the code that actually ends up in the micro's ROM. Your post above seems to imply it means something else.

ian

Reply to
Ian Bell

So do you mean the standard uses the term library to mean somethong completely different to the generally accepted meaning?

Ian

Reply to
Ian Bell

Another good reason not to use C on small embedded systems.

Ian

Reply to
Ian Bell

Quoting C99, Clause 4 "Conformance":

--- quote A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers , , , , , , and

--- ends

As you can see by looking them up, these headers restrict themselves to defining macros and types (with the possible exception of , which may need some support functions).

Well, you claimed this library was sometimes "not small enough", but apparently without bothering to find out what this library even is. Seems like you lost yourself in your own argument, to me.

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

As I have said in other posts I think we may be talking at cross purposes. What precisely do you mean by a free standing implementation?

No, you claimed there was a library that you *had* to link in any C application. I simply pointed out that in some applications *any* linked library would be too large unless you are suggesting C includes libraries of zero size?

Ian

Reply to
Ian Bell

Given the fact I just quoted you the language definition, which uses that very term, how can that possibly be unclear? But just to be overabundantly clear: I mean what the standard means by this.

I didn't. Or at least I never intended to say that --- but a misunderstanding is always possible, of course. I said that library had to be provided. I.e. it has to exist. Whether a given program uses it or not is an entirely separate question.

For the meaning of "library" used by the C standard, and some meanings of "size", yes, that's exactly what I'm suggesting. The language definition includes the definition of a library.

The fact that you assume linking a library must unconditionally increase the size of the program reveals a serious lack of understanding of the linking process, though. Linking a library doesn't mean copying all of it into the program. The size of a library is thus quite irrelevant.

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

It is unclear because you have failed to say what you (or the standard) means by the term 'free standing implemention'. When you first used it I took it to mean the code burned into ROM. From the context of your quotation I suspect it means something else to you. Hence my statement that e seem to be talking at cross purposes.

This is where we are misunderstanding eachother. I am not talking about the availability of a library but whether is has to be linked into the code that is burned into ROM. After all that is what affects code size in an embedded system - which is what I thought you meant by free standing implementation.

Which it appears is quite different to the the generally understood concept of a library.

I do realise that. What is relevant is how much of the library code actually end up in the application. My original statement is that it is not necessary for any of it so to do. Is that incorrect?

Ian

Ian

Reply to
Ian Bell

One can make a case that in at least one aspect, C is _less_ like assembler than many other high-level languages: for. Most languages only support for loops looking like FOR n=1 TO 13 STEP 2: NEXT or for n:=10 downto 1 do. Such loops are often easily caught in one, or a few, simple machine instructions. Now try the same with for (node=root; node; node=node->next) or for (i=1, j=10; x[i] && y[j]; i++, j--).

Richard

Reply to
Richard Bos

OK, then I was REALLY not getting the gist of the thread. When you say an implementation of 'C', I think the package that gets from the source code to the executable/ROMable code, not the code itself. As far as I know (or have seen in any of my cross compilers), if you don't use it the linker doesn't throw it in. I mean, what would be the purpose of linking in non-reachable code? I have also looked over the assembly output of many of my compiled 'C' programs for various projects and have never seen mysterious functions in there. Make a call to printf() and THEN you would get all kinds of crap thrown in for converting numbers to strings and so on. Call printf() with floating point turned on and you might just run out of resources on a "Hello World\n" program, on some of the REALLY resource restricted MCU's.

Jim

Reply to
James Beck

Richard wrote: ) One can make a case that in at least one aspect, C is _less_ like ) assembler than many other high-level languages: for. Most languages only ) support for loops looking like FOR n=1 TO 13 STEP 2: NEXT or for n:=10 ) downto 1 do. Such loops are often easily caught in one, or a few, simple ) machine instructions. Now try the same with for (node=root; node; ) node=node->next) or for (i=1, j=10; x[i] && y[j]; i++, j--).

I disagree.

for (a; b; c) is trivially compiled to:

label-loop: branch-if-false label-end branch label-loop label-end:

Which is a total of two branches and two branch labels. So, two asm instructions comprise the whole for loop.

SaSW, Willem

--
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
 Click to see the full signature
Reply to
Willem

From the standard:

"implementation

particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment."

--
Al Balmer
Sun City, AZ
Reply to
Al Balmer

_If_ the computation of a, b and c are trivial. The point is that in C, they can be as complex as you like. For the whole loop, you _could_ need

label-loop: branch-if-false label-end [whatever is needed for the loop body] branch label-loop label-end:

That's 1202 machine instructions for the loop itself. For the more straightforward, count-only, Basic-and-Pascal kind, all you'll ever need on many computers is:

store initial-value loop-register label-loop: [whatever is needed for the loop body] decrease-and-jump-if-not-zero label-loop

That's 2.

Richard

Reply to
Richard Bos

) _If_ the computation of a, b and c are trivial. The point is that in C, ) they can be as complex as you like. For the whole loop, you _could_ need ) ) ) label-loop: ) ) branch-if-false label-end ) [whatever is needed for the loop body] ) ) branch label-loop ) label-end: ) ) That's 1202 machine instructions for the loop itself. For the more

Those 1200 asm instructions are compiled from explicit code, written out in full in the source code. The only thing the 'for' does, is add two jumps in strategic places between those pieces of code.

SaSW, Willem

--
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
 Click to see the full signature
Reply to
Willem

In addition to the definition above, a "freestanding environment" is described as an environment "in which C program execution may take place without any benefit of an operating system."

--
John W. Temples, III
Reply to
John Temples

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.