On Apr 26, 5:50=EF=BF=BDpm, Walter Banks <wal...@bytecraft.com> wrote:> David Brown wrote: > > As for Walter's claims about his compilers generating code that is > > always smaller and faster than hand-written assembly - it is reasonable > > for him to claim that his compilers will generate smaller and faster > > code for typical applications written in C compared to the same > > applications written by the same people in assembly. > > My claim backed up by the white paper was that I can take any > asm program and recode it in C in the same or less space. This > turns all C vs asm contests into algorithms and not tools.All your proveing is that your optimiser can improve a piece of assy code, I dont doubt it can but your not comparing C vs assember.> > Knowing that the generated code size in C can't be beaten by > asm the natural advantages that C offers that are primarily > accounting makes this an important proof.No proof at all, it's not even a comparison.> > Do I expect C to be programmed like asm in most cases no, > but that fact that it can can do a lot for application optimization > and portability. =EF=BF=BDWe have had some interesting fun running > 6808 instruction test suites through a PIC compiler. > > Regards > > -- > Walter Banks > Byte Craft Limited > Tel. (519) 888-6911http://www.bytecraft.com > wal...@bytecraft.com
mixing C and assembly
Started by ●April 22, 2008
Reply by ●April 26, 20082008-04-26
Reply by ●April 26, 20082008-04-26
Chris H wrote:> In message <fuvdah$fi6$01$1@news.t-online.com>, Hans-Bernhard Br�ker > <HBBroeker@t-online.de> writes >> Chris H wrote:>>> Yes it does, very low in most cases. In fact I have seen comparisons >>> where some C compilers produce faster smaller code than assembler.>> 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.> Why?Because the above statement, as written, is obviously wrong.>> 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".> It is not obvious at all. Just as you can write good and bad C you can > write good and bad assembler.You're ignoring the fact that there's nothing in the statement under study about what I, you or anyone can write in terms of good or bad, C or assembly code. That statement is about compilers and assemblers, full stop. No people involved.> The compiler can rigorously apply optimisation in a way most humans > can't. It is reliable, repeatable and FAST.All of that is correct, but beside the point. For *every* piece of C code anyone can possibly write, in any C compilers, there's assembler code that ends up as the exact same machine code. The same is generally not true for the opposite direction. So compilers can't produce faster code than assemblers.>> 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.> C compilers can optimise and data over lay in a reliable and repeatable > way that most humans can't and compilers can do it very fast.Irrelevant, since the same, optimized code can be written in assembler. It'll take longer to write, sure, but the code won't be faster than assembler. At most it can be just as fast. And it'll take considerable extensions to the C language to make sure you never leave any gaps a competent assembler programmer can squeeze a micro-optimization through. It make take the full Walter Banks-like "I can write assembler in any language" approach to extending C to avoid this.> You seem to be arguing that the 0.001 of cases are the norm.Absolutely not. I'm arguing that the statement under study is 100.00 percent wrong. A possibly correct statement would have been "C compilers produce code faster than assemblers can do it". But "C compilers produce faster code than assembler" is wrong.
Reply by ●April 26, 20082008-04-26
Hans-Bernhard Br�ker wrote:> Chris H wrote: > > The compiler can rigorously apply optimisation in a way most humans > > can't. It is reliable, repeatable and FAST. > > All of that is correct, but beside the point. For *every* piece of C > code anyone can possibly write, in any C compilers, there's assembler > code that ends up as the exact same machine code. The same is generally > not true for the opposite direction. So compilers can't produce faster > code than assemblers.Compilers can produce some machine code that is exceedingly difficult to write and maintain in asm. These are sequences that are data or address specific that are likely to change or need to be checked each time the code is assembled. An example is the one instruction skip on the PIC that depends on knowing the lsbit of the PC. Some of these convoluted sequences require a lot of accounting that although not impossible to do by hand is reasonably prohibitive. The whole reason for HLL is to aid in making application code easier to create. I have worked hard to make sure that the language supports developer requirements in the tools we create and standards that define the tools. w..
Reply by ●April 26, 20082008-04-26
In article <48135E8A.7BA99BB4@bytecraft.com>, Walter Banks says...> > > CBFalconer wrote: > > > > 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. > > > > If you said "Anything you can write ..." I could tentatively > > agree. But not with "that can be". > > I chose my words carefully I meant "Anything that can be > written in asm for a PIC I can write in C in the same space"I'm curious Walter, how do you deal with the following sequence (for some mythical processor) in C? mul a,b,c ; b * c -> (a,b) 16bit x 16bit -> 32bit multiply div a,d ; (a,b)/d -> a 32bit / 16bit -> 16bit divide It's something I do write in asm to take advantage of a processors scaling capability. I can see something like the following could work long a; int b, c, d; a = (long)b * c; b = a/d; (assuming appropriate initialization is done somewhere). All the compilers I've seen though aren't smart enough to realize widening isn't required in this case and perform a 32bit x 32bit multiply. Even better would be if the following would work. b = ((long)b * c)/d; I don't remember it in your paper but I suspect that particular processors doesn't have the appropriate instructions. Robert ** Posted from http://www.teranews.com **
Reply by ●April 26, 20082008-04-26
CBFalconer wrote:> cbarn24050@aol.com wrote: > > > No you haven't!! > > Yes he has. In addition, the assembly programmer always has some > extra tricks available, that result in shorter and faster > programs. For example, consider a program than needs functions > foo() and bar(). It turns out that a foo call is always followed > by a bar call, but that bar needs to be separately callable. As > an example, write space to stdout, and write char to stdout. The > assembly programmer can write: > > foo: /* foo code */ > ret > > bar: /* bar code */ > ret > > foobar: call foo > call bar > ret > > but he can combine these, saving a 'ret' execution, some stack > space, and a call. The result is: > > foobar: /* foo code */ > ; /* fall through */ > bar: /* bar code */ > ret > > eliminating two calls and two rets from the earlier code. The C > programmer doesn't have this capability. Believe me, it adds up > over a medium complicated system.You mean something like this? void bar (void); void foo (void) { 0100 9D NOP NOP(); bar(); } void bar (void) { 0101 9D NOP NOP(); 0102 81 RTS } void main (void) { 0103 AD FB BSR $0100 foo(); 0105 20 FA BRA $0101 bar(); } It does add up.. Regards -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter@bytecraft.com
Reply by ●April 26, 20082008-04-26
David Brown wrote:>... snip ...> > As for Walter's claims about his compilers generating code that > is always smaller and faster than hand-written assembly - it is > reasonable for him to claim that his compilers will generate > smaller and faster code for typical applications written in C > compared to the same applications written by the same people in > assembly.That is due, in part, to the fact that todays programmers have not had heavy exercise in their chosen assembly language. This, in turn, follows from the fact that each assembly language has to be learned on its own. But I still maintain that an expert in assy language A can always do better than an expert C programmer using a compiler for A. Note the 'experts'. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
Reply by ●April 26, 20082008-04-26
Walter Banks wrote:> CBFalconer wrote: >... snip ...> >> If you said "Anything you can write ..." I could tentatively >> agree. But not with "that can be". > > I chose my words carefully I meant "Anything that can be > written in asm for a PIC I can write in C in the same space" > > Take a look at the white paper. Its examples are for RS08 > but we have done this with the PIC's as well.What white paper? URL please. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
Reply by ●April 26, 20082008-04-26
Walter Banks wrote:> CBFalconer wrote: >... snip ...> >> but he can combine these, saving a 'ret' execution, some stack >> space, and a call. The result is: >> >> foobar: /* foo code */ >> ; /* fall through */ >> bar: /* bar code */ >> ret >> >> eliminating two calls and two rets from the earlier code. The C >> programmer doesn't have this capability. Believe me, it adds up >> over a medium complicated system. > > You mean something like this? > > void bar (void); > void foo (void) > { > 0100 9D NOP NOP(); > bar(); > } > void bar (void) > { > 0101 9D NOP NOP(); > 0102 81 RTS } > void main (void) > { > 0103 AD FB BSR $0100 foo(); > 0105 20 FA BRA $0101 bar(); > > It does add up..Well, that looks impressive, but you must be loosing something. You must be doing something illegal and non-understandable (to a C programmer) with one or more of indentation, braces placement, illegal statements (a call to foo should never enter bar). I see no reason for bar to exit while foo falls through. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
Reply by ●April 26, 20082008-04-26
On Apr 27, 1:52=EF=BF=BDam, CBFalconer <cbfalco...@yahoo.com> wrote:> David Brown wrote: > > ... snip ... > > > As for Walter's claims about his compilers generating code that > > is always smaller and faster than hand-written assembly - it is > > reasonable for him to claim that his compilers will generate > > smaller and faster code for typical applications written in C > > compared to the same applications written by the same people in > > assembly. > > That is due, in part, to the fact that todays programmers have not > had heavy exercise in their chosen assembly language. =EF=BF=BDThis, in > turn, follows from the fact that each assembly language has to be > learned on its own. =EF=BF=BDBut I still maintain that an expert in assy > language A can always do better than an expert C programmer using a > compiler for A. =EF=BF=BDNote the 'experts'.I'm not so sure you need to be an expert to beat C.> -- > =EF=BF=BD[mail]: Chuck F (cbfalconer at maineline dot net) > =EF=BF=BD[page]: <http://cbfalconer.home.att.net> > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD Try the downlo=ad section.> > ** Posted fromhttp://www.teranews.com**
Reply by ●April 27, 20082008-04-27
cbarn24050@aol.com wrote:> CBFalconer <cbfalco...@yahoo.com> wrote: >... snip ...> >> That is due, in part, to the fact that todays programmers have not >> had heavy exercise in their chosen assembly language. �This, in >> turn, follows from the fact that each assembly language has to be >> learned on its own. �But I still maintain that an expert in assy >> language A can always do better than an expert C programmer using a >> compiler for A. �Note the 'experts'. > > I'm not so sure you need to be an expert to beat C.Why do your quotes have those ugly "�" characters in them? They were not in my original article. You are not the only one generating them. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
