Walter Banks wrote:
If you ask me, ISO/IEC 18037 is close to useless (at least, if it's the
document which is also known as WG14 N1021).
- the fractional types are nice, but inconsistent. Why should a
'short fract' have fewer bits than 'short int'?
- named address spaces: wouldn't it be much more useful to define a
general mechanism to place things in sections? This would also help
Unix people.
- it still doesn't have a useful C-to-asm interface. The most useful
interface I've seen so far is gcc's.

Hence, what I've seen implemented so far all looks a little different.
Fortunately, they implement gcc's asm extensions, at least partially :-)

What optimization could be applicable to a piece of code which
initializes few registers and then jumps to a label?

A question that comes up for me is: if I write 'SP = expression', can I
use a complex expression? What if the compiler decides it needs to spill
some temporaries onto the stack? (and what if it does that only under
specific circumstances, like a special set of runtime checks enabled?
During my still short life, I've already seen quite some code that
breaks even if you turn on optimisation, because suddenly the compiler
notices that the delay loops actually don't do anything.)

Hence if I want a specific assembler sequence in the program, I write it
in assembler. Startup code is one such case. And, hey, those three
instructions won't kill you. But of course, I'll try to get into the
high-level language as fast as possible. Actually, my current boot
loader (final code size somewhere below 2k) even contains some C++
modules :-) But its tight main loop (decompression+decryption) would
probably have been impossible to write in a compiled language.


Stefan

Stefan Reuther wrote:

Because the short modifier isn't size specific. Use C99's size specific
data types

Named address space is for data memory processors data spaces
and ROM spaces.
Sections are one approach. ISO is responsible for documenting
standard practice. Write a paper describing an alternative
approach to named address space using sections and send it
to WG14. (Contact me off line for contact details)

ISO/IEC 18037 is a technical report not yet part of the C standards
make a case for changes based on experience. My experience
with 18037 has been that it has made coding small embedded systems
and DSP systems a lot easier. Fixed point math provides data
types with a focus on precision rather than dynamic range was
missing from C. This addition makes many applications
possible on very small processors.


Get GCC to participate in the standards process. It would help everyone
especially GCC

Jump paging. Why not let the compiler do the work.

Yes.

When you access the lowest levels of the processor there is
an assumption that the developer understands the consequences.


It varies from compiler to compiler.

I'm have never suggested that you shouldn't use asm it is an
implementation choice. I am saying there is no compelling
reason to use asm for startup code.

In earlier threads we showed a proof where any asm program
could be written in C in the same or less code space or execution time.
The specific white paper was for a very small 8 bit processor.

http://www.bytecraft.com/C_versus_Assembly


Regards,

Walter..

"Walter Banks" <walter@bytecraft.com> wrote in message
news:48108425.240346E6@bytecraft.com...
Good point.

On that sort of machine, you'd have to consider what you were going to use
that stack for before you'd use up 1/8 (or even half) of your resources to
handle that particular "it'll never happen" scenario.

I usually work on systems with a lot more stack resource than that, so
pushing a two or four byte return is using a very small percentage of that
resource. A reasonable trade off in those environments.

- Bill

Neil wrote:
So is he.

There are small bits of the startup that must be in assembler (I use
embedded assembly within the C code - Walter uses C extensions in his
compilers that translate directly to matching assembly). But most of it
can be written perfectly well in C. For example, code to copy the
initialised data from flash to ram, and to zero the bss, can be written
in C.

On Apr 24, 1:44�pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:
They teget them to get money from people like you.

PICs, and ImageCraft's dedicated
I have yet to be convinced that any meaningful program can be written
in C for these small devices. Maybe you could post yours.


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.


�These are devices aimed at

On Apr 24, 1:59�pm, Walter Banks <wal...@bytecraft.com> wrote:
Hence the need to avoid C altogether.

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

No, I can't post my code - it was a project for a paying customer.

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

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.


No, calling functions is *one* feature of C. It is not the *only*
feature of C (maybe you're thinking of Forth?). 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.

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

w..

In message <4811D3FC.421D6AD5@bytecraft.com>, Walter Banks
<walter@bytecraft.com> writes
You won't convince him. Some people just argue for the sake of it and
have "religious" beliefs rather than engineering common sense. :-(

It's like people arguing over 35mm film V DSLR or CD verses LP's. They
are blinded by numbers and theoretical arguments etc.

In reality C has been used on many safety critical systems. Errors that
have caused multiple fatalities have been caused by assembler (FADEC).
The Arianne 5 rocket crashed and that had flight controls written in
Ada. It is not about the language.

The other thing that really pisses me off is that all programmers who
produce commercial tools are always assumed to be lying or not
presenting the truth or in some way biassed in any discussion of tools.

Yet programmers who are paid to produce software other than these tools
are always totally honest. (And FOSS types always walk on water they
are so saintly and have no bias whatsoever even if they do produce other
commercial SW or systems)

Walter has always been (AFAIKCS) completely honest and open (NDA's not
withstanding) on this NG. The fact he has earned a good living writing
tools he sells for longer than he cares to admit should point to his
honesty. Unless all the people he sells his tools to are complete
idiots or deluded?

Given Walters involvement in the automotive industry and the amount of
SW created with Bytecraft compilers that is in vehicles currently on the
road we KNOW his tools are good. Otherwise you would have automotive SW
failing all over the place.

Of course as I distribute Bytecraft (for money) anything I say must be
null and void I suppose?

The argument that I distribute certain tools because in my professional
opinion, as a developer for many years and some one who works with
Walter on international standards, they are good reliable tools will
not hold water with the nay -sayers because I can not be trusted because
it is commercial..... :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Walter Banks wrote:
If you said "Anything you can write ..." I could tentatively
agree. But not with "that can be".

--
[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:
I wasn't criticizing that 'short fract' doesn't have a precise size. I
was criticizing that its recommended size differs from that of 'short
int'. Confusing IMHO.

Of course, one could argue that a 'long double' has more bits than 'long
int', so a precedent is set. But to me, 'fract' types are almost the
same as 'int' types.

Existing practice looks like this: __attribute__((section("foo"))),
#pragma section "foo", section("foo"). I'd love to see something like
that with a standard syntax. I think WG21 (C++) is discussing it.

I would prefer such an approach over a fixed set of keywords because it
allows solving several similar problems with similar syntax.

My experience is that none of the compilers I looked at support it (ADI,
GHS, GNU, MS, Microchip). Or they have hidden it well enough :-P

If you know how to think like a compiler, you can manage that. I'm a
hobbyist compiler writer, so I know how a compiler thinks. Most of my
colleagues don't. But even to me, estimating when a compiler will spill
a variable to the stack is hard.

But we all can read processor manuals and understand assembler.

They're writing assembler with C syntax, and showing are that their
instruction chooser's patterns match the processor. Not too realistic if
you ask me.

In reality, one would declare variables normally (not by assigning them
to fixed processor registers), and it would be an interesting C-vs.-asm
test to see how the compiler assigns them to registers. At least, that's
one reason why I use a compiler: it is much better at keeping track of
register assignments over a dozen screenfuls of code than I.

That aside, what does the compiler do when I use a register in my code,
but the compiler needs it to evaluate an unrelated complex expression?


Stefan

On Apr 25, 8:32Â*am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
I have no idea what kind of person you are.

Â*I am a believer in using the right tool for the
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.


Allways the same excuse, everyone seems to have a million dollars
worth of code on PIC.


True but C doesn't have low overheads.


Â*The choice of language is a matter of
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.


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.


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


Â*It is not the *only*
I'm still waiting for Forth on a PIC.


Â*Certainly, most C
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!!

On Apr 25, 1:52�pm, Walter Banks <wal...@bytecraft.com> wrote:
You can convert asm into primitive C and have your compiler change it
back but where does that get you. 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.

On Apr 25, 6:14�pm, Stefan Reuther <stefan.n...@arcor.de> wrote:
Your righter than right, thats exactly what he's doing.

Stefan Reuther wrote:

Actually the debate in WG14 started that way that their should be
corresponding fract types to int types. There are several issues that
needed to be addressed. The first was a signed fract had one
less bit of significance than unsigned fract. Eventually the debate became
focused on the relationship between accum and fracts and support
for DSP applications and the data size of a default _Fract became
the same as an int with provision for other fract types.

Most of my experience with 18037 is in compilers that support
automotive engine controllers and cell phone DSP's. As we release
updates for small embedded systems compilers 18037 support is
part of what we ship.


That is the reason that our listing files look as much like asm lists as
possible. Embedded systems especially needs good system understanding

It is not the kind of code anyone is likely to write. But it is a proof that
anything written in asm can be written in the same space as C. It is
also proof that the C compiler knows the whole ISA.

Compilers are good at account operations, overlaying variables and
register tracking for example.

Depends on the processor. Processors that have an ac and index, the
registers are volatile and over written. Risc processors like the xgate and
some of the engine controllers can have some global variables in registers.
The compiler respects the application declarations.


w..

In message
<72b456ce-494f-43ac-8735-a8ea924caccf@26g2000hsk.googlegroups.com>,
cbarn24050@aol.com writes
Yet you said:-
You can't have it both ways.

Yes.. Or at least the cost of re-inventing it is far higher than
continuing with the current code base.

Yes it does, very low in most cases. In fact I have seen comparisons
where some C compilers produce faster smaller code than assembler. In
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.


The answer is "yes" I don't know of any embedded C compilers you can't
try before you buy. Some are size limited and others time limited. Some
companies like IAR offer both size and time limited versions of some of
their compilers.

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.


:-)


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Walter Banks wrote:
A blackfin qualifies as either, doesn't it?

Sure, still I think it's a useless proof. One writes C because one
doesn't want to know about the C<->asm correspondence. 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.
Assuming state-of-the-art compilers, I'd expect both to end up in the
same region for most application tasks.

(That aside, I would have expected a line like 'a - b;' to be completely
optimised away instead of compiled into a 'cmp' or 'sub' insn.)

So if I place a variable in the accumulator, the compiler does not use
it anymore for arithmetics? How does it compile 'b = c + d' on a machine
that does arithmetics only on the accumulator (like a Z80)?


Stefan

cbarn24050@aol.com wrote:

It gets the accounting advantages of C. Variable reuse, register
tracking, memory management and tracking.

Having proven that any asm can be written in the same size (or less)
in C then the focus becomes application implementation where the
C compiler as an implementation aid that does well the two things
that asm programmers don't do easily.

1) Accounting

2) With every change in an application algorithm start over and
code again.

Regards

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

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.


Ive seen the code limited versions, not quite the full package are
they. As for time limited, thats not really much help is it. Thats why
they can afford to do it.



Yes lets do that. Some small project on a small PIC so everyone can
build and get working without spending too much money. Rules: Write
your code, program device, verify it meets the project spec, post the
memory map, and object file so everyone else can verify your program
works.

Yes indeed but you havent written in C you've written in assember.


No you haven't!!

then the focus becomes application implementation where the
With only a few variables it's not that taxing.

Rarely does that happen but Ive seen many a C function junked and
started over.