pic c

How would you code stack thunks, iterator routines, or coroutines (like the PDP-11's "JSR R5, @(SP)+" style) written in assembler? Or critical code edges written in assembler to have the same execution time? Etc.

Like you said, I know these are classic c vs asm stuff and I note you quoted the "any" part. So if I narrow your point enough, I can accept it. Just thought I'd say hi.

Jon

But this isn't so, Walter. Would you be willing to take an application I have, which has documentation on the reasoning for identical timing of code edges (a requirement) as well as the use of iterator code (for dramatic improvements in code compactness as well as containing traversal 'knowledge' in a single routine where it belongs?)

I think the problem here is that you start out by defining a subset you wish to consider.

Jon

I can't believe you are saying this so broadly, Walter. I read your

3-pager already and it is leading. However, you do try and appear to be conservative, as well. Kind of having it both ways.

But this comment is quite explicit. And I think you know it's wrong. There is no level playing field, even with access to processor registers.

I guess you feel up to sticking your neck out, though. Up for a challenge?

Jon

Jon,

I wondered when you would weigh in. :)

Stack space is just another named address space that is always accessed with reference to the SP. In your PDP-11 example

JSR R5, @(SP)+

becomes

*(SP++) = R5; R7 = R5;

This is a classic. Neither C or asm has syntax to support time specific descriptions. The implementation problem is the similar in both approaches. In the asm implementations of time specific code application developers do cycle counting which works well for processors with predictable execution times. Short edges are padded with one of several effective NOP's in every instruction set.

The same code and same processor implemented in C compiler depends on the compiler metrics and instruction selection to calibrate the edges.

Both of these solutions suffer from interrupt jitter or interrupts are forced to be turned off.

Most new processors solve the problem differently again in both C and asm. These processors have variable execution time per instruction or can be assumed to have interrupt jitter solve that timing problem by pre-computing a result for a specific time and waiting for an event to release the result. This is how time processors like the eTPU achieve constant timing.

In the RS08 compiler and the support we are adding to other similar processors (PIC for example) to aid in time specific code we added a high level dispatcher that is known at the compiler level that launches execution threads triggered by hardware and software events. When these threads are used they are run to completion.

Walter Banks

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

snipped-for-privacy@bytecraft.com

Sorry, Walter. I wasn't talking about emulating the instruction. I was using the instruction to point to a larger concept using a short hand to do it.

C doesn't support the concept well. One of the places I've encountered a need for it is in writing division code, for example. But that is only one tiny example. In fact, I'm thinking about having you demonstrate your other claims using an example of some floating point division code I've written.

Jon

The definition for each instruction is an emulation in C . It is up to the compilers optimizer to create the correct single instruction.

*(SP++) = R5, R7 = R5; this if I had a PDP-11 compiler would generate JSR R5, @(SP)+

Walter Banks

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

snipped-for-privacy@bytecraft.com

I think I need to provide a more complete example of what I was pointing towards.

Jon

Well I dont see a real test, show me one. I would expect for a typical pic project coded independantly in C and asm the C program to be at least 5 times bigger. I'm more than happy to look at any evidence you have to the contrary.

If the compiler is smart enough to do that, even if the functions are ordered differently (normally "DoSomething" would come first in a C program), then it is pretty smart.

I've had occasion to write assembly code that is going to be much more difficult than this to translate into C - things like multiple entry points to routines, coroutines, tables that overlap with code, etc., but examples would take too long here. It sounds like you can deal well with most code, however.

It is often *easier* to write clever code in C, especially if maintainability of the code is important, but it will *always* be the case that any code that can be written in C, no matter how clever, can be written at least as small and fast in assembly (given enough time and programmer skill), while the opposite is not true. The point of using modern compilers is not that they can somehow generate impossibly good code - it is that they can generate better code than assembly programming in almost all real-life cases.

This last point I don't agree with. With a C compiler that can optimize small sequences each describing one instruction of the whole instruction set and producing one instruction we have proof that we can then take any asm program translate it into C and and compile it into a program the exact same size as the asm program.

From that proof we logically say that we can make any C program the same size or smaller than an asm benchmark.

I am not disputing that at all. This all started a few months ago as part of a compiler validation excise. The result of the exercise has a lot of implications in the asm vs C debate and some approaches to application development.

I am not trying to argumentative on this point, just pointing out what we did and extrapolating the implications.

We have been aware for 3 or 4 years that it was possible to encode the instruction set in C. We did most of the eTPU instruction set in C when we wrote the code generator for it. The RS08 was the first full instruction set that we implemented in C and compiled back to single instructions. Since then we have done 2 more.

Walter Banks

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

snipped-for-privacy@bytecraft.com

You cannot be serious claiming that.

"Any C program can be coded in ASM"

is true (perhaps impractical with some - many - assembly syntaxes);

the reverse is simply not true and you should know it.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Walter Banks wrote:

He's already explained in detail that it is true for at least one platform/compiler combination. He's also explained _how_ it's done. Unless you're going to provide some evidence to impeach him, I'm going to believe his explanation: it seemed

100% plausible, and I'm pretty confident I could produce a compiler that could do the same thing.

While it's possible using the method describe to write any arbitrary assembly program in C, IMO the resulting C code may end up more difficult to maintain than the assembly. I would think that the requirement to write multiple C statements to generate a single desired machine instruction would make it _more_ difficult to accomplish the task rather than easier.

Not only does the programmer have to remember the target instruction set, he has to remember what pattern of C statement(s) he needs to write to generate each instruction he desires.

--
Grant Edwards                   grante             Yow! Hmmm ... a CRIPPLED
                                  at               ACCOUNTANT with a FALAFEL
                               visi.com            sandwich is HIT by a
                                                   TROLLEY-CAR ...

I am not interested in PIC programming, nor in any pointless theoretical debates.

Well, how cute. So people now have the opportunity to remember how to express a particular micro's assembly line in several lines of C. Very advanced indeed. I am sure portability will also be claimed...

Dimiter

Nor am I. Friends don't let friends use PICs.

Nobody forced you to join the thread. You jumped into the middle of a somewhat theoretical discussion of language/compiler theory and called somebody a lier.

If they desire. Nobody claimed it was a practical alternative to writing assembly in a production environment, only that there is a demonstrable way to do it.

It's quite interesting.

I don't believe so, but nice straw man.

Are you now backing away from your accusation that Walter was lying about having a compiler that can generate any arbitrary assembly program? Did you even read the paper describing how it's done before declaring it to be impossible?

--
Grant Edwards                   grante             Yow! My NOSE is NUMB!
                                  at               
                               visi.com

You are right. I shold have stayed out of it.

I _never_ called him a liar. This is your interpretation alone.

While I am sure you can extend C (or any other language) until it covers any existing assembly language 1:1, using the same or a different syntax, I still think that this is sheer nonsense.

Again, I never said he lied. I have no reason to think he does not believe what he writes.

I will back off my claim that this is "not true" (see explanation above on any language) without reading the paper, I'll take your and Walters word for it.

I was looking at it from a practical point of view.

PICs apart, but on PPC, 68k, 68xx, TI DSPs and perhaps some others I know and cannot think of now this is sheer, impractical nonsense; doable, OK, so many pointless things are doable.

Dimiter

Yes, you did. Walter said that he has a compiler that can do "X". You then said that "X" is not possible and Walter knows it.

He didn't "extend C", and it doesn't cover the assembly langauge 1:1.

You're certainly allowed your opinion that doing "X" isn't a useful thing to do. That, however, is far from your original statement that "X" is not _possible_ to do, and that somebody claiming to do "X" _knows_ it's not possible.

You stated that what he wrote was not true and the he knows it's not true. In my book, you called him a lier.

Then we've no argument.

Fine. Everybody agrees that from a practical point of view it's not a feasible replacement for assembly language. You've knocked that straw man down.

You seem to be pre-occupied with PICs.

The compiler being discussed happens to be for the 6808, but the principles involve are pretty general.

Now that you've shifted your argument from "it's not possible" to "it's not practical", there's no disagreement.

--
Grant Edwards                   grante             Yow! I want the presidency
                                  at               so bad I can already taste
                               visi.com            the hors d'oeuvres.

Are you saying you don'tmake the difference between "you should know it" and "you know it".

Please do not misquote me. I did not call him a liar, nor did I think he was.

OK, so let's see how this can be done (I am looking at some

6809 code which could also be 6800):

ENTRY1 LDB #1 FCB $8C to skip the next two bytes ENTRY2 LDB #2 FCB $81 SKIP NEXT BYTE ENTRY3 CLRB .....

I am not saying it is impossible - perhaps he has figured a way to do that in standard, non-extended C - but I am surely curious to see how it is to be done and what it will look like.

Dimiter

So is it possible to do that simple piece of code in C as claimed or do we have to revoke the "not true" clause. Here it is with binary included (manually assembled using a skill which had been in retirement for 20+ years...).

2000 org $2000 2000 C6 01 ENTRY1 ldb #1 prepare value in B-acc. 2002 8C dc.b $8c skip next two-byte opcode (CPX # to it) 2003 C6 02 ENTRY2 ldb #2 prepare another value in b 2005 81 dc.b $81 skip next 1-byte opcode (cmpa to it) 2006 5F ENTRY3 clrb 2007.....further code using the value of B

Can you show us how to do that in C?

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

This is pretty trivial stuff for a compiler. First of all, rather than writing incomprehensible code, you'd write it using branches in C (goto's or tailcalls).

The branch optimizer will place the instructions next to each other to minimise branch instruction size (so you get the above but with branches).

Next the optimizer could change branches that branch 1 or 2 bytes forwards into 2-3 byte instructions that have "no effect". Compares can often be used, but any instruction that doesn't change state will do as the compiler knows which registers and flags are live at any given point. This kind of low-level modification is often called peepholing.

The interesting thing about compilers is that while they apply mostly very basic optimizations, they do lots of them repeatedly and consistently, and often come up with new combinations of optimizations the compiler writer hadn't thought of. Effectively compilers are smarter than the people who wrote them...

Now self modifying code would be more of a challenge to do in C!

Wilco