faster smaller code than assembler. 0 >> some cases an experienced assembler programmer can produce, in the same
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.
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
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.
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.
To be agreed... Lets see your first offering of the rules.
Yes. We will need an agreed spec.
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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.
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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).
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.
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 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.
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.
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.
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?
Try:
formatting link
or
formatting link
I haven't tried them, but they are the first hits on google for "forth pic".
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.
The real comparison is the efficient amount of dollars spent to solve the problem.
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
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]:
Try the download section.
** Posted from http://www.teranews.com **
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
e faster smaller code than assembler. 0 >> some cases an experienced assembl= er programmer can produce, in the same
m
Oops, touched on a raw nerve there.
Who said I was that good?
espite being
Life
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.
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.
No offence was mean, perhaps I should have said peaple in your position.
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.
n
You could allways ask for permission..
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
I dont think it is.
=BDI find
an
I think you missed the whole point of the language.
=C2=A0Have you ever actually written programs in C, or are you
Because the above statement, as written, is obviously wrong.
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.
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.
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.
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.
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.
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.
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]:
Try the download section.
** Posted from http://www.teranews.com **
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]:
Try the download section.
** Posted from http://www.teranews.com **
I don't think generalisations like that are appropriate, no matter how you phrase them. But don't worry - no offence taken.
As I say, you are not likely to get useful direct evidence here. Even if someone posts some code (such as Walter's white paper), it's easy to say "that's just a test case". The same applies the other way too. So all you get is witness declarations, which you can credit or not.
I *could*, but I won't. Again, it would be unprofessional.
Choose the tools that work for *you*.
But for most people (even good, experienced assembly programmers) and most applications, C is normally a better choice of development language.
I'm not making claims that C compilers always generate smaller and faster code than assembly - just that with a good C compiler, C is an appropriate choice of language even on small devices like AVR Tinys.
There are some sorts of code that can be coded more compactly in assembly, and other sorts of code where the compiler can optimise better than an assembler programmer writing clear and maintainable assembly code.
What you are saying, in a somewhat exaggerated fashion, is that C is a procedural programming language (although it is more correct to say that C *supports* procedural programming). That's true, but it is also an imperative programming language. That is to say, most lines of C code are declarations or statements saying how a task is to be accomplished - function calls are only one type of statement or expression available to the programmer (compare this to Forth, in which a much higher percentage of statements are calls). Splitting your code into separate functions is an important aspect of structured programming in C - but it is not the "whole point of the language". Most assembly programmers divide up their code into functions and procedures in a similar manner to C programming.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.