pic c

e instruction for each asm description in C. (Incidentally

I would love to eat those words, I'd buy one tommorow if it could be demonstrated. Sadly whenever the challenge is put forward it's allways declined.

for

I'd have to dissagree with you there. Are you a half decent C programmer? Would you like to try? I would be very interesed to see how close the new C compilers get.

=EF=BF=BDThere can be occasions when assembly is still the best tool

instruction for each asm description in C. (Incidentally

You can send the order to snipped-for-privacy@bytecraft.com or call sales at 519 888 6911 :))

There is a PDF on Byte Craft's website that demonstrates the process used to define the full instruction set in C and validate the low level compiler optimization that demonstrates this proof.

go to the website

and follow the links to

or download the following PDF

We have been doing this for last few years as test to uncover obvious missing optimizations in our compilers.

Regards,

Walter Banks

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

snipped-for-privacy@bytecraft.com

Jim I saw the "there" it jumped out at me after the send and I was too late for the cancel to have in an effect. I really needed the second cup of coffee to speed up my reaction time, the adrenaline from the bear raiding the bird feeders Saturday night on the deck had worn off.

Seriously, the compiler technology is moving forward. ISO TR 18037 gives us the ability to do what C intended solid low level support for processors. The RS08 example in the PDF shows why this is important in effective code generation.

Regards

Walter Banks

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

snipped-for-privacy@bytecraft.com

This is the process exactly.

Two comments on this

1) Details of instructions vary but the meaning may be the same or similar. What we found was when compiling on a different processor the very low level C still maps well. For example code written to map well to a MAC on a DSP processor will generally map to a MAC well to a MAC on a different processors because the functionally is similar. The two compilers deal with the different implementation details.

2) Compiling asm to C instead of machine language puts a new meaning in portability.

Done

Walter Banks

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

snipped-for-privacy@bytecraft.com

It isn't asm either. You still get tracking and optimization that C gives. The code will generally compile and run on other platforms. It is interesting running an instruction test suite on compiler for another processors. Missing registers can be declared as vars and the code still runs. The two compiler's sort out the differences between carry handling between the different processors for example.

It happens but always in cases the asm could have been optimized but wasn't for one of several reasons. Compiler tracking and optimization sees things that asm programers don't.

I know these are classic C vs asm arguments. My point is with ISO 18037 support I can take "any" asm program for the target processor and recode it in C with no embedded asm and compile with equal or less RAM and ROM requirements.

Walter Banks

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

snipped-for-privacy@bytecraft.com

ingle instruction for each asm description in C. (Incidentally

1 =A0:))

to define the full instruction set in C and validate the low level compile= r optimization that demonstrates this proof.

sing optimizations in our compilers.

I've read this, it proves nothing except a very simple C statement that matches an existing machine code can be can be translated one for one. Thats light years away from saying a project coded in C is as small as one coded in assembly. If you want a real test first devise a project, build the hardware to run it, have it coded in C and assembler and see what you get. Then look for your excuses.

Well, I'm in the real world, and it is of interest to me :) (and many others).

I don't really care about the semantics of (quoting cbarn) "Oh yes you can do that, but then your not really writing in C are you."

You write code to get a job done, if it is called High level Assembler, or low level C, or not really C, is of little import.

For low level embedded work, getting close to the silicon will always be important, and a better C compiler technology, that allows that without the discontinuity of change to 'pure assembler' IS an advance.

Yes, the programmer should be able to scan the ASM created, and verify the compactness, but they no longer need to write in pure-asm, and can instead use the C-Level-Asm, and take the logistics gain.

It makes a better tool: What comes out of the tool, still depends on the craftsman wielding it.

-jg

For every instruction in the instruction set.

This also means that no assembler implementation of an application can be written tighter than is possible in C.

We recode asm benchmark code in C almost every week here and I don't need to apologize for the results. The assertion I made yesterday means we can do it and the generated code will be at least as short and fast in C implementation.

w..

Thats not the same thing at all. Completly meaningless. Do the real test and see.

Unfortunately, I am more than half-decent as a C programmer (and assembly programmer on a number of targets), making it a poor comparison!

It is not often that I have written code for the same job in both assembly and C for a direct test. I have certainly seen cases where my assembly code has been significantly smaller and faster (by a factor of

3 or 4) than C code for the same application, because assembly gives you the freedom to build your code in different ways - C limits you to a more structure procedural paradigm. I have also seen cases where particular functions can be better written in assembly, even compared to modern tools. However, in a great many test cases, a good C compiler will generate fairly close to optimal code for functions.

If you are going to compare C and assembly, then it is important to remember that you should *not* compare the smallest, fastest assembly you can write with the compiler-generated code. For a fair comparison, you should be comparing to a well-written, maintainable assembly program. Remember, a C compiler can happily hold much more information "in its head" when generating code, and it can take advantage of things like constant values in ways that an assembler writer cannot, as long as the program is to remain flexible and maintainable. For example, a compiler has no problems shuffling local variables around in different registers, while an assembler writer would perhaps keep the same variable in the same register so that the code is legible.

My understanding is that these extensions to C are designed to mirror assembly, and allow you to write something like "mov a, b" or "add r0, r1" in your C code, and have it generate a single instruction. Obviously there are times when this is exactly what you need - embedded programs sometimes need access at a lower level than C itself allows, or they want to take advantage of particular target features (such as multiply-accumulate units).

Having such a facility and calling it "C" also means that you can take any given assembly program, make a few syntax changes, and call it "C" - pass the code through the compiler, and you end up with virtually the same object code thus proving that the compiler can generate code at least as small and fast as "assembly". It is this proof that is technically correct, but irrelevant in the real world.

As for the real uses of these extensions, I am somewhat sceptical. It is rare that I need to use embedded assembly in my C programming, and when I do, it is target-specific. It is utterly irrelevant to me if the embedded assembly that works on the AVR fails on a ColdFire, and I see no advantage in having a common syntax for the instructions themselves. There are three common uses for embedded assembly that I can think of

- access to low-level functions (such as setting up the initial stack, or disabling interrupts), using extra cpu features (such as dsp functions), and implementing low-level OS functions (such as task switching). All of these are processor specific.

What would be useful is a consistent way to implement embedded assembly. The gcc "asm" instruction is extremely powerful, and allows C code to be optimised around the "asm" code, but has a somewhat cryptic syntax. I've seen other syntaxes for other compilers with different pros and cons - an extension to standardise this would be most welcome.

That's certainly the case.

mvh.,

David

Out of curiosity, how do you handle code structures that do not fit C's procedural organisation? For example how do you treat code like:

DoSomethingTwice: call DoSomething DoSomething: ; ... ret

And how do you express instructions like the COP8's "DCOR" (decimal correction) instruction, or "RETSK" (return with skip) ?

While I have no doubts that your compiler generates excellent code, and have few doubts that it generates smaller and faster code than most reasonably written, maintainable assembly equivalents, there will always be times when assembly gives the programmer greater freedom than C to write clever code.

Not quite. What you describe is in-line-assembler, and that supports std opcodes - so it is quite a mind-shift.

What Walter has done, is allow more implicit access, so the Compiler 'knows' about X, ACC, and the objective is to try and reach every opcode.

ASM C

0100 4C INCA AC++; 0101 2F INC X X++; 0102 26 INC $06 tiny++; 0103 3C 15 INC $15 small++; 0105 3C 34 INC $34 page0++; 0107 4A DECA AC--; 0108 5F DEC X X--; 0109 56 DEC $06 tiny--; 010A 3A 15 DEC $15 small--; 010C 3A 34 DEC $34 page0--;

I'm not sure what % Op-Code coverage Walter achieves (high nineties I'd guess?), but as you mention in another post, there are sometimes a couple of opcodes that are hard to map to. Decimal adjust is likely to be one.

Yes, but to someone who is NOT as familar with the mnemonics, or someone else who has to maintain the code, there is an advantage.

With my code, I will do more 'live mixing' than that. eg on the 80C51, which we use, we code the MUL opcode as in-line assembler, and then use HLA access to the result. This gives access to a '16 bit' result, without having to type all variables as INT, and it is significantly smaller and faster as a result. Yes, it is processor specific.

This standard gets close to that, but is not just an ASM window, but gives a way to map nearly all opcodes to C Source lines. It thus pushes the need for true in-line assembler further down

-jg

From what I could see from Walter's paper, this is not anything to do with the proposed C extensions. He has just combined a few compiler-specific details so that his variables can be allocated in user specified areas (very useful for small processors), with an excellent code generator. He is checking the quality of the code generator, and showing it to be as good as possible, rather than making a new sort of embedded assembler. In fact, he is specifically disabling some of his compiler's cleverness by using "volatile" in the definitions of these variables - otherwise in the above code, references to "small" would disappear.

If you are not familiar enough with the mnemonics to be able to interpret them (with the datasheet on hand, of course), then you really should not be messing with the embedded assembly in the first place. There is some justification for wanting to get a bit of regularity to some artificial mnemonics (for example, to give a consistent ordering to the source and destination operands, which varies between assembly languages). But by the time you get to the "rd = rs;" level, you're writing plain old C anyway.

I would say that all you need is a decent "asm" format combined with macros and/or inline functions, and you can reduce almost all mention of embedded assembly to a single target-specific header file.

mvh.,

David

We do real tests all the time. We start out equal and then the C compiler advantages kick in.

- Per Compile full application strategy passes

- Variable re-use

- Data bases of optimization

The real power is the languages understanding of the underlying processors registers and architecture.

Walter Banks

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

snipped-for-privacy@bytecraft.com

The extensions in ISO 18037 basically allows the compiler to recognize the underlying processor registers. This means that you can reference the condition code bits directly and the compiler has specific information in the code generator to recognize the condition codes referenced in source and act on that information.

registercc CC; // Declare the condition code register

if (CC.C == 1) { . . . } // if carry is set execute

01A7 B9 D0 ADC $0210 AC = AC + var + CC.C;

"small" in the example was declared as a variable. Your right we had to force the compiler not to optimize out some of our test code.

The point is not to create another assembler but to make sure that the C compiler has full access to the processor. The way to check if the C compiler can fully access the processors is to create a test suite that encodes the full instruction set in C. If that can be done then we have proof that any asm program can be written in the same or smaller space in C.

I am not advocating writing code that way. The instruction encoding in C is primarily a compiler test with interesting implications to the developer. Now that we have a level playing field to start with between C and asm. C can be no worse than an ASM implementation.

The things that C compilers do well come into play.

- Do a full implementation every time they compile

- Variable allocation management in multiple memory spaces

- Variable re-use

- Control and data flow management

- Data bases of optimization "tricks"

These are all familiar arguments in the endless asm vs C discussions. When it comes down to it compilers do accounting better than people.

Walter Banks

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

snipped-for-privacy@bytecraft.com

procedural

A good compiler will use tailcalls where possible, so when you write:

void DoSomethingTwice(void) { DoSomething(); DoSomething(); }

it is translated to a call and a branch. The next step is to place DoSomethingTwice immediately before DoSomething as part of branch chain removal (so the branch gets removed). I have no idea whether Walter's compiler does this but it is likely he already reorders code to minimise branch instruction size. This is just a case where the branch size becomes zero.

correction)

Most instructions can be represented directly in standard C, but the few cases that can't (or are too complex to write out all the time) would use intrinsics. So A = __DCOR(A) or more explicitly A = __DCOR(A, CC). RETSK could be done as a variant of return, eg __return_next. Whether it is useful in general is doubtful though...

few doubts

maintainable

programmer

Absolutely, that's why assembler will continue to be used by experienced people who can still beat a good compiler... The problem is that there aren't that many good assembly programmers, and the ones that are, are usually also very good C programmers...

Wilco

Create a functions out of DoSomething and DoSomethingTwice:

void DoSomethingTwice (void) { DoSomething(); DoSomething(); }

void DoSomething (void) {

}

The compiler is smart enough to know from the strategy pass that the two functions follow each other and the second DoSomething() call will generate no code and just fall into the DoSomething function.

We have implemented DAA,DCOR and variants as long logical statements that get matched. Remember all of this test exercise that proves the compiler can be programmed in C and will generate the whole instructions set. Not every instruction is pretty.

The opposite is also true where some very clever code can be now written in C.

The only time that I can see when asm might be needed is for for timing specific code. There is no syntax in C to specify execution time requirements on the generated code. However lots of developers do write time specific code in C in applications.

There are processors that specifically support code for time specific applications. eTPU used in automotive engine controller applications for example.

Walter Banks

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

snipped-for-privacy@bytecraft.com