Chris H wrote:
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.

In message
<e1018830-3d20-4d38-836a-891e4e3d657f@b1g2000hsg.googlegroups.com>,
cbarn24050@aol.com writes
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <fuvdah$fi6$01$1@news.t-online.com>, Hans-Bernhard Bröker
<HBBroeker@t-online.de> writes
Why?

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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

cbarn24050@aol.com wrote:
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:

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".

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.

Stefan Reuther wrote:

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
http://www.abvolt.com

cbarn24050@aol.com wrote:
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 **

David Brown wrote:

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

CBFalconer wrote:

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

On Apr 26, 3:19�pm, Chris H <ch...@phaedsys.org> wrote:
Oops, touched on a raw nerve there.





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.


You could allways ask for permission..
Been there, done it many times, thats why I have this position.


Â*> As for Walter's claims about his compilers generating code that is
I dont think it is.

I think you missed the whole point of the language.


Â*Have you ever actually written programs in C, or are you


I'll have a look.

On Apr 26, 5:50�pm, Walter Banks <wal...@bytecraft.com> wrote:
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.


No proof at all, it's not even a comparison.

Chris H wrote:
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.

Hans-Bernhard Bröker wrote:

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..

In article <48135E8A.7BA99BB4@bytecraft.com>, Walter Banks says...
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 **

CBFalconer wrote:

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

David Brown wrote:
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 **

Walter Banks wrote:
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 **

Walter Banks wrote:
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 **

On Apr 27, 1:52�am, CBFalconer <cbfalco...@yahoo.com> wrote:
I'm not so sure you need to be an expert to beat C.

cbarn24050@aol.com wrote:
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 **