mixing C and assembly

Because the short modifier isn't size specific. Use C99's size specific data types

Named address space is for data memory processors data spaces and ROM spaces. Sections are one approach. ISO is responsible for documenting standard practice. Write a paper describing an alternative approach to named address space using sections and send it to WG14. (Contact me off line for contact details)

ISO/IEC 18037 is a technical report not yet part of the C standards make a case for changes based on experience. My experience with 18037 has been that it has made coding small embedded systems and DSP systems a lot easier. Fixed point math provides data types with a focus on precision rather than dynamic range was missing from C. This addition makes many applications possible on very small processors.

Get GCC to participate in the standards process. It would help everyone especially GCC

Jump paging. Why not let the compiler do the work.

Yes.

When you access the lowest levels of the processor there is an assumption that the developer understands the consequences.

It varies from compiler to compiler.

I'm have never suggested that you shouldn't use asm it is an implementation choice. I am saying there is no compelling reason to use asm for startup code.

In earlier threads we showed a proof where any asm program could be written in C in the same or less code space or execution time. The specific white paper was for a very small 8 bit processor.

Regards,

Walter..

Good point.

On that sort of machine, you'd have to consider what you were going to use that stack for before you'd use up 1/8 (or even half) of your resources to handle that particular "it'll never happen" scenario.

I usually work on systems with a lot more stack resource than that, so pushing a two or four byte return is using a very small percentage of that resource. A reasonable trade off in those environments.

- Bill

So is he.

There are small bits of the startup that must be in assembler (I use embedded assembly within the C code - Walter uses C extensions in his compilers that translate directly to matching assembly). But most of it can be written perfectly well in C. For example, code to copy the initialised data from flash to ram, and to zero the bss, can be written in C.

p?

et), the

ort).

But

ted text -

They teget them to get money from people like you.

PICs, and ImageCraft's dedicated

hat I

I have yet to be convinced that any meaningful program can be written in C for these small devices. Maybe you could post yours.

find

Exactly! you cant. C is nested language, functions calling functions calling functions. Thats one reason why it isn't so good on these small chips.

=EF=BF=BDThese are devices aimed at

.- Hide quoted text -

Hence the need to avoid C altogether.

text -

Are you trying to imply that I am the sort of person that will buy any tool just because it says "C" on the box, and I think "C is always better than assembler"? I am a believer in using the right tool for the right job, and I won't part with any money unless I see the tool giving value for money. Thus for AVR Tiny work, I used avr-gcc - but I'd recommend ImageCraft's AVR Tiny compiler for most users (avr-gcc is easy to use for normal AVR's, but a bit more challenging for tiny's). I used C because it was the better choice for my development - if it were inappropriate, I would have had no problem writing the code in assembly.

Or are you implying that the companies behind these tools are selling worthless tools to gullible punters? Walter Banks can answer for his own ByteCraft tools, and I can tell you that ImageCraft wrote their AVR Tiny C compiler because customers asked for it. Prices are very low - if you are doing significant work with AVR Tiny's, you'd have a hard time justifying *not* buying it.

No, I can't post my code - it was a project for a paying customer.

If you can write a meaningful program in assembly for a device, you can also write a meaningful program in C (and in Forth, and Ada, and Pascal, hand-compiled pseudocode, and any other language that can generate object code with low overheads). The choice of language is a matter of what you find most suitable as a source language for writing the code.

Perhaps you mean to say that you don't think there are C compilers that can generate code for the AVR Tiny (or PICs, or whatever) with low enough overhead that they can be sensibly used on such small micros. The explanation for that is simply that you have not tried good modern compilers.

It is certainly the case that you can do more tricks with assembly than in C, and you have a greater freedom in structuring your code. I've written assembly code where the program code and data tables overlapped at the edges to save space - you can't do that sort of thing in C. But unless you are willing to work particularly hard at it, a C compiler will give you as tight code as you would write in assembly on such a micro.

No, calling functions is *one* feature of C. It is not the *only* feature of C (maybe you're thinking of Forth?). Certainly, most C programs are going to have a call tree of more than three levels - but small programs will not necessarily need that many levels.

You are also ignoring the difference between the abstract, source code view and the generated object code. In the source code, you may define separate functions and call them - the compiler may then inline them when generating the object code and thus avoid the stack usage.

Hide quoted text -

I think you confusing the limitations of the silicon with the language tools you are using. Anything that can be written in asm for a PIC I can write in C in the same space.

w..

If you said "Anything you can write ..." I could tentatively agree. But not with "that can be".

I wasn't criticizing that 'short fract' doesn't have a precise size. I was criticizing that its recommended size differs from that of 'short int'. Confusing IMHO.

Of course, one could argue that a 'long double' has more bits than 'long int', so a precedent is set. But to me, 'fract' types are almost the same as 'int' types.

Existing practice looks like this: __attribute__((section("foo"))), #pragma section "foo", section("foo"). I'd love to see something like that with a standard syntax. I think WG21 (C++) is discussing it.

I would prefer such an approach over a fixed set of keywords because it allows solving several similar problems with similar syntax.

My experience is that none of the compilers I looked at support it (ADI, GHS, GNU, MS, Microchip). Or they have hidden it well enough :-P

If you know how to think like a compiler, you can manage that. I'm a hobbyist compiler writer, so I know how a compiler thinks. Most of my colleagues don't. But even to me, estimating when a compiler will spill a variable to the stack is hard.

But we all can read processor manuals and understand assembler.

They're writing assembler with C syntax, and showing are that their instruction chooser's patterns match the processor. Not too realistic if you ask me.

In reality, one would declare variables normally (not by assigning them to fixed processor registers), and it would be an interesting C-vs.-asm test to see how the compiler assigns them to registers. At least, that's one reason why I use a compiler: it is much better at keeping track of register assignments over a dozen screenfuls of code than I.

That aside, what does the compiler do when I use a register in my code, but the compiler needs it to evaluate an unrelated complex expression?

Stefan

le

uoted text -

I have no idea what kind of person you are.

=C2=A0I am a believer in using the right tool for the

Ive never used AVRs tiny or otherwise but I have used PICs extensively. I am convinced that C is pretty much useless on the small devices. If you or anyone else thinks different then post some code for a real project.

sed

hat

y that I

Allways the same excuse, everyone seems to have a million dollars worth of code on PIC.

True but C doesn't have low overheads.

=C2=A0The choice of language is a matter of

Well can you get "try before buy" compilers? Can you get your money back if the compiler doesn't meet your expectations? I think we know the answer to both questions.

ut

Not a chance, challenge me if you want, Walter did but changed his mind after I told him he couldn't have my assembly code untill after he'd done it in C.

=BDI find

Wrong, thats the whole point of the language, programs within programs. Each block is isolated from the next, self contained, runs in its own space, memory allocated as needed at run time and released when finished with. Anything between braces is independant (or at least sould be).

=C2=A0It is not the *only*

I'm still waiting for Forth on a PIC.

=C2=A0Certainly, most C

ne

Indeed but then it used more limited code space instead. Worse still you make a small change to a product, you probably thought "this wont be hard", the compiler then changes its mind about inlining and it wont fit anymore, and you dont know why!!

ent.- Hide quoted text -

You can convert asm into primitive C and have your compiler change it back but where does that get you. What you cant do is write in C and get it as small as an asm program, at least not as easily as writing in asm in the first place.

help

Your righter than right, thats exactly what he's doing.

Actually the debate in WG14 started that way that their should be corresponding fract types to int types. There are several issues that needed to be addressed. The first was a signed fract had one less bit of significance than unsigned fract. Eventually the debate became focused on the relationship between accum and fracts and support for DSP applications and the data size of a default _Fract became the same as an int with provision for other fract types.

Most of my experience with 18037 is in compilers that support automotive engine controllers and cell phone DSP's. As we release updates for small embedded systems compilers 18037 support is part of what we ship.

That is the reason that our listing files look as much like asm lists as possible. Embedded systems especially needs good system understanding

It is not the kind of code anyone is likely to write. But it is a proof that anything written in asm can be written in the same space as C. It is also proof that the C compiler knows the whole ISA.

Compilers are good at account operations, overlaying variables and register tracking for example.

Depends on the processor. Processors that have an ac and index, the registers are volatile and over written. Risc processors like the xgate and some of the engine controllers can have some global variables in registers. The compiler respects the application declarations.

w..

In message , snipped-for-privacy@aol.com writes

waste a third of your stack resources.-

Yet you said:-

You can't have it both ways.

Yes.. Or at least the cost of re-inventing it is far higher than continuing with the current code base.

Yes it does, very low in most cases. In fact I have seen comparisons where some C compilers produce faster smaller code than assembler. In some cases an experienced assembler programmer can produce, in the same time frame, an application that is smaller and faster than the C program but it is not common.

The answer is "yes" I don't know of any embedded C compilers you can't try before you buy. Some are size limited and others time limited. Some companies like IAR offer both size and time limited versions of some of their compilers.

Well lets draw up a competition and agree the rules. You will probably need some one independent to hold the produced code until all have completed their solution.

:-)

A blackfin qualifies as either, doesn't it?

Sure, still I think it's a useless proof. One writes C because one doesn't want to know about the Casm correspondence. There are dozens of language-X-versus-language-Y comparisons, where a programmer fluent in X solves a problem in X and then ports it to Y, ignoring most of Y's idioms. As a result, X usually is faster. Such a comparison is bogus. A realistic comparison would be to let a programmer fluent in X solve the problem in X (for example, X="C"), and another one fluent in Y solve the problem in Y (for example, Y="asm"), and then compare the results. Assuming state-of-the-art compilers, I'd expect both to end up in the same region for most application tasks.

(That aside, I would have expected a line like 'a - b;' to be completely optimised away instead of compiled into a 'cmp' or 'sub' insn.)

So if I place a variable in the accumulator, the compiler does not use it anymore for arithmetics? How does it compile 'b = c + d' on a machine that does arithmetics only on the accumulator (like a Z80)?

Stefan

It gets the accounting advantages of C. Variable reuse, register tracking, memory management and tracking.

Having proven that any asm can be written in the same size (or less) in C then the focus becomes application implementation where the C compiler as an implementation aid that does well the two things that asm programmers don't do easily.

2) With every change in an application algorithm start over and code again.

Regards

-- Walter Banks Byte Craft Limited Tel. (519) 888-6911

ons

=BDIn

Well I havent, post some, or if your worried about secrecy email it to me. Ive written several projects in both languages, the asm version has allways been much smaller.

=BDSome

Ive seen the code limited versions, not quite the full package are they. As for time limited, thats not really much help is it. Thats why they can afford to do it.

Yes lets do that. Some small project on a small PIC so everyone can build and get working without spending too much money. Rules: Write your code, program device, verify it meets the project spec, post the memory map, and object file so everyone else can verify your program works.

/\/\/\/\/

Yes indeed but you havent written in C you've written in assember.

No you haven't!!

then the focus becomes application implementation where the

With only a few variables it's not that taxing.

Rarely does that happen but Ive seen many a C function junked and started over.

Then I think you should publish the names of those studies' authors here

--- so we can all make sure we never believe anything they write, ever again. Given the fact that by the very definition of assembler all code that runs on a given machine can be written in it, it's perfectly obvious that there can be no such thing as "faster, smaller than assembler".

Yes, people may produce better code using C than assembler, if given the same amount of other resources. But that's a property of people, not compilers or assemblers.