What micros do you actually hate to work with?

The key words are "a good assembly programmer", I guess. They seem to be very scarce... To add to your point, a good assembly programmer will typically be able to beat by a factor of at least 10 a C written code in terms of speed and memory resources.

But these are things which have been commented a lot. The real question I have after reading this thread (not specifically related to the posting I quote) is "why do some people use a processor they hate to use?". E.g. I hate to use Intel, have looked into their architecture over the years hoping to see some progress which would make them usable (I mean the x86) for me, well, no luck so far. The same mess on a larger scale (well, I have not looked last

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

CBFalc> > Roman wrote:

Well, take the x86 you noted as an example, you may not like to embed it into a product, I may not like to embed it into a product, but there is a huge advantage for the customer who creates/debugs/simulates his application code on a $400 PC, using whatever complier he already owns, and knows that when he downloads it into the embedded x86 system it will run exactly the same way, yielding the exact same results for a given get of inputs.

=_NextPart_000_0052_01C6EC42.D06D52A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What a load garbage!!!!!!!!!!! Are you trying to say that you could = write 1k of code output from C code in 100 bytes of assembler???????? Statements like this are so misleading and biased. I agree assembler is = more compact and has its place in certain situations but please don't = exagerate so.=20 C so far leads in terms of cost in writing & maintaining code, and = simplifying complex data structures etc that are a nightmare in = assembler. Yes, assembler for very small processors, but for the majority of = projects C is so much more practical. Just like C has it's limitations = when you move up into the bigger embedded systems using 32 bit = processors where you would move onto C++ just to allow you to more = easily manage the project. Sure... C++ is not as resource friendly as C = which in turn is not as resource friendly as assembler, but in terms of = practicality it horses for courses.

PhilW

I beg to differ. C++ is about as resource friendly as C. Runtime features would take extra resource (e.g. virtual class will require a VTAB pointer in each object), but compile-time features like inheritance, templates, strong typing etc. do not require any resources.

This misconception about C++ being resource hungry may exist because C++ is usualy used on complex projects with plenty resources (Windows) and these programmers tend to be resource sloppy. Example: we had a PIC project, which got inherited by a good C++ Windows programmer. This guys added OS and was using 32-bit integers all over the PIC program, so he was running out of precious RAM (1.5k) pretty fast. He wasn't even using C, just was programming PIC same way as he programs in Windows.

of code output from C code in 100 bytes of assembler????????

If Didi was writing in binary, that's a factor of 10, or 512 bytes...

--Gene

of code output from C code in 100 bytes of assembler????????

How many projects in C have you managed to put into 1k. I am saying what I am saying, my try seems successfull enough.

is so much more practical.

Whatever you say... I won't go into a C assembly debate now because it is meaningless (which assembler, for which architecture). I can back my words by projects I have done (check my website, all you see there has been done without a line of C). Think whether you can match it in C and how long it will take you based on extrapolation of your work so far. Then think you see just the tip of the iceberg.

Please be specific if you want to go any further on that, arguments of the "everybody says so" kind have no value. C has its place among computer users (allows them to think they are programmers :-) :-), but it does waste a factor of 10 of the resources at best (it can easily go to a factor of 1000+ in MS' products, but that's hardly related).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

P.S. Are you sure you need that html thing in your postings? I could well do without having to delete it.

PhilW wrote:

of code output from C code in 100 bytes of assembler????????

compact and has its place in certain situations but please don't exagerate so.

complex data structures etc that are a nightmare in assembler.

is so much more practical. Just like C has it's limitations when you move up into the bigger embedded systems using 32 bit processors where you would move onto C++ just to allow you to more easily manage the project. Sure... C++ is not as resource friendly as C which in turn is not as resource friendly as assembler, but in terms of practicality it horses for courses.

I was writing decimal. To most of the C programmers I have met, I can do that a hex. I don't know which group you belong to....

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Gene S. Berkowitz wrote:

of code output from C code in 100 bytes of assembler????????

=_NextPart_000_0044_01C6EBD6.3044C5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree. Historically, C took twice the space of assembly, but modern optimized C compilers have gotten that down to just 20%. Unless, that extra 20% code space is a MUST, then its hard to justify NOT using C over assembly.

None, And in such cases I would agree that assembler would probably be the way to go since you are obviously using a small mcu that is doing a little control and thats about it. Even so writing in C would still be quite possible, unless of course in writing your assembly you recursively calling into yourself all the time making code maintence a nightmare. C is very close to assembler level and if written that way produces code very close to what you would do in assembly. I know that C can be abused and produce terrible code, but I have found if you approach it in light of what the mcu wants it produces very good code.

I am not trying to have a C assembly debate. As I have already said, there are situations where either would be the better way to go. What I questioned was your statement that assembly is 10 times better. I believe that to be an exagerated overstatement. I believe that, since I do code in both C and assembly. C is my preferred since the results are quicker and generally more maintainable. Have you programmed in C? your absolute distaste for it makes it sound like you haven't.

I'd like to know on what you base this factor of ten on. In my experience as a "real programmer" and a "think I am a programmer" it is nowhere near that. I have never used 10 times more variable memory locations, or seen a program run 10 times slower, or used 10 times more code space when writing in C over assembler. In fact I rather find they are somewhat similar, although better in assembler. The loss in writing in C was worth it for the gains in having easy code maintainability. In one product I was involved in I originally wrote it in assembler which was fine. But when called upon to expand it and the data structures became more and more complex, the shift to C made it a breeze to maintain and read. A big plus in the bottom line of time = money.

of code output from C code in 100 bytes of assembler????????

is so much more practical.

of code output from C code in 100 bytes of assembler????????

compact and has its place in certain situations but please don't exagerate so.

simplifying complex data structures etc that are a nightmare in assembler.

is so much more practical. Just like C has it's limitations when you move up into the bigger embedded systems using 32 bit processors where you would move onto C++ just to allow you to more easily manage the project. Sure... C++ is not as resource friendly as C which in turn is not as resource friendly as assembler, but in terms of practicality it horses for courses.

C allows me to write code for the PIC16. Otherwise I would hate it to. The 1 interrupt is annoying enough.

.tpgi.com.au...

snipped-for-privacy@m73g2000cwd.googlegroups.com...

or

er

en

Not true, even now C is much bigger than 2 times code space. The biggest difference shows up in small projects where it can easily reach the times 10 factor.

That will happen if you use standard libraries and don't pay attention to what is being added, the classic culprit is printf which can add the entire floating point library if you don't pay attention, but there are other things to watch (depending on whos library)

There was a time when 2X was the code space difference but even for small projects I haven't seen much more than a 20% improvement and often not even that. I have had several jobs with people who preferred assembly (and some were pretty good assembly programmers) and in terms of time (to write and debug) C has always been faster and definitely easier to maintain, the 5-15% (average) space penalty and under 10% execution speed penalty. If the processor selected was that close to the limit then we had more serious problems

Stan Katz

don't pay attention to

ays

ty

Why would anyone want prinf on a small project? Ask yourself this, how many commercial projects have you seen written in C in under 1k? 2k? or even 4k? Why do C compiler vendors give away compilers that are limited to 4K? Why are there billions of sold chips with memories in the 0.5k, 1k, 2k ect size? Why dont the processors designed specifically for C available in rom sizes less tha n 16k?

Many.

We have written C compilers that supported processors that had less than a K of memory.

There are lots of reasons for doing this. Compilers are better at accounting than people making it easier for a compiler to maintain information on RAM allocation and reuse. Everytime a compiler has started it has a fresh look at how the code should be implemented this time. C compilers use the full instruction set. C compilers enforce instruction set usage including manufactures suggested practices and work arounds for silicon restrictions (features). Compilers can do maintainable optimizations on many processors that are not possible to maintain in hand written assembler. For example address dependent code sequences found on many small micro's

The C vs assembler arguments are getting old. There are a few reasons that some people use assembler there are many good reasons to use compiled code. In the straight assembler vs C argument after the ISO changes in TR 18037 we started writing the instruction set in C and compiling as one of our release test suites to make sure that every machine instruction could be written in C and compile to one instruction.

Some notes on this can be found at

Walter..

Many.

It would have been nice if you had given a detailed example of one.

a K of memory.

ing than people making it easier for a compiler to maintain information on = RAM allocation and reuse. Everytime a compiler has started it has a fresh l= ook at how the code should be implemented this time. C compilers use the fu= ll instruction set. C compilers enforce instruction set usage including man= ufactures suggested practices and work arounds for silicon restrictions

sors that are not possible to maintain in hand written assembler.

For example address dependent code sequences found on many small micro's

What are you talking about here? Please give an example.

t some people use assembler there are =A0many good reasons to use compiled = code.

In the straight assembler vs C argument after the ISO changes in TR

I'm not sure what this paragraph means.

"Didi" skrev i meddelandet news: snipped-for-privacy@i3g2000cwc.googlegroups.com...

Have several complete C projects for customers that fit into an ATtiny13... The latest project (not functional) was totally written in assembly language, and after rewriuting it in C, I managed to reduce the code by 10%. Writing in assembler is generally a waste of time on an AVR...

Many mobile phone accessories fit into 8 kB and below. Several of these fit into less than 4kB. A few, very high volume will fit into less than 1 kB. There are of course projects requiring 16/32/64 and 128 kB as well.

- All mobile phone accessory projects I have seen, and I have seen many, are programmed in C, none in assembler.

Because they think that they can win additional business since a customer is going to use a variety of sizes, and if they are happy with the 4k compiler they will buy the compiler in the end.

Because ROMs are only used for old tech devices :-)

ATtiny13 w 1 kB is perfectly capable of executing C code, and in all assembler examples I got from customers, I could rewrite in C with same or better result.

As usuall no details, so no way to make any real evaluation.

Whats a mobile phone accessory?

cause they think that they can win additional business since a customer is

Thats right, you spend your time using the free version, then you find your project doesn't quite work without you having to buy the the full compiler.

never happy but too far in to back out.

Ha Ha , nicely ducked.

That doesn't prove anything as you well know.

It's more a sign of a novice, that a want.

I've done quite a few sub 1K projects in a HLL, ( but I'll admit I use Modula-2, and not C), and I also use the 80C51, which gives compact code.

The earlier claim of 10:1 is simple arm-waving nonsense: sure, you can find an inept C-coder, who uses printf, and float, and compare that with a experienced ASM coder, but what is the point - you are far from comparing like with like ?

In fact, HLL code can often be smaller than ASM done in the same time-frame, as HLL allows the luxury of trying more than one algorithm, and code sharing is more common in HLL than ASM, (which tends to be coded 'brick by brick', with a fear of touching anything already laid down.

Everyone using a HLL in uC situations, _should_ have a pretty good feel for what output it will produce. Once they have that ability, there is little HLL penalty.

Not sure I follow the question - because they choose to ?

? - because they do the task ?

Examples ? I've seen a lot of spin from vendors claiming "designed specifically for C", on all sorts of uC....

In the smallest projects we've handled, I've found lack of RAM more an issue than CODE size, and you can see that reflected in Atmel's pruning of AVRs without any RAM, but they still offer small code models. [ 80C51's have always had >=128 bytes of RAM ]

-jg