Chris H wrote:> In message > <72b456ce-494f-43ac-8735-a8ea924caccf@26g2000hsk.googlegroups.com>, > cbarn24050@aol.com writes>> True but C doesn't have low overheads.> 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. 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.
mixing C and assembly
Started by ●April 22, 2008
Reply by ●April 26, 20082008-04-26
Reply by ●April 26, 20082008-04-26
In message <e1018830-3d20-4d38-836a-891e4e3d657f@b1g2000hsg.googlegroups.com>, cbarn24050@aol.com writes>> Yes it does, very low in most cases. 0 >> where some C compilers produce faster smaller code than assembler. 0 >> 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. > >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.There is always some one who can beat the compiler just as there is always some one who can run a sub 4 minute mile. However in reality the vast majority can do neither.>Ive seen the code limited versions, not quite the full package are >they.Yes it the full package. Is just a limit on the size of the code generated. Actually the bits that are missing (if any) are usually the utilities, source code etc. nothing that affects the compiler> As for time limited, thats not really much help is it. Thats why >they can afford to do it.Stop whining. There are always people who will find fault with everything. If you are that good programming a time or size limited compiler for evaluation will tell you all you need to know about it's capabilities. On the other hand I expect you will find a reason why despite being the worlds best assembler programmer you can't use a size or time limited compiler.>> 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. > >Yes lets do that. Some small project on a small PIC so everyone can >build and get working without spending too much money.Money isn't the problem. It's time. And to be frank (currently doing three months VAT accounts) I don't have the time to waste on you. Life is too short and this problem is mainly in your head anyway.> Rules:To be agreed... Lets see your first offering of the rules.> Write >your code, program device, verify it meets the project spec,Yes. We will need an agreed spec.>post the >memory map, and object file so everyone else can verify your program >works.No... They will have to go to a third party to ho9ld until all are finished and all the results posted at the same time to ensure no in appropriate optimising. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●April 26, 20082008-04-26
In message <fuvdah$fi6$01$1@news.t-online.com>, Hans-Bernhard Br�ker <HBBroeker@t-online.de> writes>Chris H wrote: >> In message >><72b456ce-494f-43ac-8735-a8ea924caccf@26g2000hsk.googlegroups.com>, >>cbarn24050@aol.com writes > >>> True but C doesn't have low overheads. > >> 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?>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. The compiler can rigorously apply optimisation in a way most humans can't. It is reliable, repeatable and FAST.>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. Given an application and a time limit the C compiler will produce a faster and smaller application than most humans. Given an infinite amount of time I am sure that in a given instances some programmers may be able to beat a C compiler but it is not going to be common. You seem to be arguing that the 0.001 of cases are the norm. If cbarn was moved to a totally new MCU he has never seen before it will take him a long time to beat a compiler, if at all. Though at the moment I am trying to beat a deadline for a company Tax return... :-( -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●April 26, 20082008-04-26
cbarn24050@aol.com wrote:> On Apr 25, 8:32 am, David Brown <da...@westcontrol.removethisbit.com> > wrote: >> cbarn24...@aol.com wrote: >>> On Apr 24, 1:44�pm, David Brown <da...@westcontrol.removethisbit.com> >>> wrote: >>>> cbarn24...@aol.com wrote: >>>>> On Apr 24, 12:43 am, David Brown >>>>> <david.br...@hesbynett.removethisbit.no> wrote: >> <snip> >>>>>> Secondly, some processors have small fixed-size hardware stacks (small >>>>>> PIC's and AVR Tiny's are examples). �For such devices, a single >>>>>> unnecessary "call" can waste a third of your stack resources.- Hide quoted text - >>>>> Firstly you would be mad to try running C of these chips. Secondly you >>>>> would not put call returns on the hardware stack unless you have some >>>>> kind of death wish, you keep that space for the ISRs. >>>> Firstly, you must then call me mad, along with all the customers for PIC >>>> C compilers targeted at the smallest >>> They teget them to get money from people like you. >> 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 have no idea what kind of person you are. >That's why I found it odd that you thought referred to "people like you". It's a dangerous phrase to use - "people like you" can easily sound very insulting (fortunately I'm well used to Usenet, and don't take offence easily).> 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 > > 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. >If you want to see real C code for PICs or AVR Tiny's, you'll have to search the web. "People like me" have free time enough for some idle banter on Usenet, but not nearly enough to waste writing sample applications to convince someone who has already made up his mind.> >> 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. >> >>> PICs, and ImageCraft's dedicated >>>> AVR Tiny C compiler. �I've only used a Tiny once, but I wrote that >>>> program in C (using gcc - with a bit of arm-twisting to make it work >>>> without RAM). �I studied the generated assembly - it is unlikely that I >>>> could have improved on it more than a few percent if I had hand-write >>>> the assembly. >>> I have yet to be convinced that any meaningful program can be written >>> in C for these small devices. Maybe you could post yours. >> No, I can't post my code - it was a project for a paying customer. > > Allways the same excuse, everyone seems to have a million dollars > worth of code on PIC. >My code is for the AVR Tiny, and it's not worth a million dollars. In fact, since the project seems to be stopped (not because of the software!), it's probably not worth anything. Nonetheless, I'm a professional, and cannot post the code.> >> 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). > > True but C doesn't have low overheads. >If you use a good C compiler, then it *does* have low overheads. Of course, you have to stick to features of C that are appropriate for such small systems - if you use library functions like printf, dynamic memory, or floating point operations, then you'll quickly use up lots more resources than are available on the device.> > 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. > > 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. >I don't know about you, but the answer everyone else knows is "yes". All commercial compilers I have used or looked at seriously have trial or demo versions - I've even had an offer from a supplier (for a much larger toolkit for a much bigger processor) who was happy to lend me a complete kit including manuals, CDs, dongle, and demo boards so that I could test their compiler and tools. And of course, the avr-gcc compiler I used on the AVR Tiny is totally free anyway.> >> 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. > > 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. >No one has time to take these sorts of challenges seriously, even if it were possible to write an application that proves the point. If you want to see how well a C compiler will work for *your* sort of programs, on *your* chosen target, then *you* can download a trial or demo version of the compilers available, and try it out yourself. Anything done by others is fairly worthless - you can either accept the experience of other people, or do the work yourself. 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.> >> >>>> Secondly, the AVR Tiny has no ram beyond its 32 cpu registers. �I find >>>> it hard to imagine that you could write a program that needed more than >>>> 3 levels of calls (including interrupts) and have space in those >>>> registers to make a software call stack. >>> 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. >> No, calling functions is *one* feature of C. > > 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). >That's an amazingly inaccurate way to describe any programming language, especially C. Have you ever actually written programs in C, or are you mixing up C and UNIX?> > It is not the *only* >> feature of C (maybe you're thinking of Forth?). > > I'm still waiting for Forth on a PIC. >Try: http://tutor.al-williams.com/picforth1.htm or http://www.ram-tech.co.uk/ I haven't tried them, but they are the first hits on google for "forth pic".> > 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. > > 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!! >Inlining can be a trade-off between code space and stack space and run-time, although very often it leads to smaller code as well as less stack and run-time. And any good compiler will give you as much or as little control over inlining as you want.
Reply by ●April 26, 20082008-04-26
Stefan Reuther wrote:> 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.The real comparison is the efficient amount of dollars spent to solve the problem.> Assuming state-of-the-art compilers, I'd expect both to end up in the > same region for most application tasks.Yes, yes and yes. Since 30 years ago they keep telling us that C had almost reached the performance level of the assembler :) There are the things where the high level languages perform traditionally poor: mixed size or non-native size arithmetics, the multiple indirections, and the use of the CPU features such as modulo addressing, saturation, etc. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●April 26, 20082008-04-26
cbarn24050@aol.com wrote:> >>> You can convert asm into primitive C and have your compiler >>> change it back but where does that get you. >> >> It gets the accounting advantages of C. Variable reuse, register >> tracking, memory management and tracking. > > Yes indeed but you havent written in C you've written in assember. > >>> 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. >> >> Having proven that any asm can be written in the same size (or >> less) in C > > 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. -- [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
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. 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. 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. We have had some interesting fun running 6808 instruction test suites through a PIC compiler. Regards -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter@bytecraft.com
Reply by ●April 26, 20082008-04-26
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" Take a look at the white paper. Its examples are for RS08 but we have done this with the PIC's as well. Regards -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter@bytecraft.com
Reply by ●April 26, 20082008-04-26
On Apr 26, 3:19=EF=BF=BDpm, Chris H <ch...@phaedsys.org> wrote:> In message > <e1018830-3d20-4d38-836a-891e4e3d6...@b1g2000hsg.googlegroups.com>, > cbarn24...@aol.com writes > > >> Yes it does, very low in most cases. 0 >> where some C compilers produc=e faster smaller code than assembler. 0 >> some cases an experienced assembl= er programmer can produce, in the same> >> time frame, an application that is smaller and faster than the C progra=m> >> but it is not common. > > >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. > > There is always some one who can beat the compiler just as there is > always some one who can run a sub 4 minute mile. However in reality the > vast majority can do neither.> > As for time limited, thats not really much help is it. Thats why > >they can afford to do it. > > Stop whining. There are always people who will find fault with > everything.Oops, touched on a raw nerve there.> > If you are that good programming a time or size limited compiler for > evaluation will tell you all you need to know about it's capabilities. >Who said I was that good?> On =EF=BF=BD the other hand I expect you will find a reason =EF=BF=BDwhy d=espite being> the worlds best assembler programmer you can't use a size or time > limited compiler.> > >> 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. > > >Yes lets do that. Some small project on a small PIC so everyone can > >build and get working without spending too much money. > > Money isn't the problem. It's time. And to be frank (currently doing > three months VAT accounts) I don't have the =EF=BF=BDtime to waste on you.=Life> is too short and this problem is mainly in your head anyway.A cop out in other words as per usuall. By the way I do my quarterly VAT return in about 2 hours manualy. I expect your accounts are on the computer. There should be a button that does it for you in 2 minutes.> > > Rules: > > To be agreed... Lets see your first offering of the rules. > > > Write > >your code, program device, verify it meets the project spec, > > Yes. We will need an agreed spec. > > >post the > >memory map, and object file so everyone else can verify your program > >works. > > No... They will have to go to a third party to ho9ld until all are > finished and all the results posted at the same time to ensure no in > appropriate optimising.No!! why not? I'm not suggesting posting source code. Do you think someone would reconstruct an object file? I guess we could have a release day after all participants have agreed they have completed. Third party involvement seems a bit over the top dont you think.> > -- > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > \/\/\/\/\ Chris Hills =EF=BF=BDStaffs =EF=BF=BDEngland =EF=BF=BD =EF=BF=BD=/\/\/\/\/> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●April 26, 20082008-04-26
> > I have no idea what kind of person you are. > > That's why I found it odd that you thought referred to "people like > you". =C2=A0It's a dangerous phrase to use - "people like you" can easily > sound very insulting (fortunately I'm well used to Usenet, and don't > take offence easily).No offence was mean, perhaps I should have said peaple in your position.> > 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. > > If you want to see real C code for PICs or AVR Tiny's, you'll have to > search the web. =C2=A0"People like me" have free time enough for some idle=> banter on Usenet, but not nearly enough to waste writing sample > applications to convince someone who has already made up his mind.My mind is quite open to change, this is why I ask for some evidence. Nobody can ever produce any, I wonder why. Haveing built many projects in both languages I have seen first hand the differences.> >> No, I can't post my code - it was a project for a paying customer. > > > Allways the same excuse, everyone seems to have a million dollars > > worth of code on PIC. > > My code is for the AVR Tiny, and it's not worth a million dollars. =C2=A0I=n> fact, since the project seems to be stopped (not because of the > software!), it's probably not worth anything. =C2=A0Nonetheless, I'm a > professional, and cannot post the codeYou could allways ask for permission..>> > 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. > > No one has time to take these sorts of challenges seriously, even if it > were possible to write an application that proves the point. =C2=A0If you > want to see how well a C compiler will work for *your* sort of programs, > on *your* chosen target, then *you* can download a trial or demo version > =C2=A0 of the compilers available, and try it out yourself.Been there, done it many times, thats why I have this position. =C2=A0> 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.I dont think it is.> > > >>>> Secondly, the AVR Tiny has no ram beyond its 32 cpu registers. =EF=BF==BDI find> >>>> it hard to imagine that you could write a program that needed more th=an> >>>> 3 levels of calls (including interrupts) and have space in those > >>>> registers to make a software call stack. > >>> 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. > >> No, calling functions is *one* feature of C. > > > 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). > > That's an amazingly inaccurate way to describe any programming language, > especially C.I think you missed the whole point of the language. =C2=A0Have you ever actually written programs in C, or are you> mixing up C and UNIX?> > > > > =C2=A0 It is not the *only* > >> feature of C (maybe you're thinking of Forth?). > > > I'm still waiting for Forth on a PIC. > > Try: > > http://tutor.al-williams.com/picforth1.htm > > or > > http://www.ram-tech.co.uk/ > > I haven't tried them, but they are the first hits on google for "forth pic=". I'll have a look.>
