C

Bingo!

I am using printf for fun. Thanks for the tip. Now I can get rid of printf and replace it with atan and maybe be under the 4K limit.

This project is a very small project and should be done in less than 2K.

As I said, I'm a newbie to all this compiler stuff and Andy (and others) have given me good clues to work on.

I'd say that the paragraph following 'nominal' says it all.

I read, and quoted, the one and only paragraph in your post.

"The most I have ever saved by writing an assembler module is $0.83 but that sold 860.000 units (you do the math)"

To compute the real net saving, we'd have to know the cost of writing the assembler; ie, the cost of the extra time that it took you to manually optimise it into assembler.

(I don't doubt that there was a real net saving)

Lou;
Since cost and size of code was a concern, suggest that you look at some of the ARM Cortex-M3 devices by Luminary, ST and NXP. The eval tools have a 16K limit offset by 16K. Also, there are other tools that support C and C++. Cost of the chips are well within reach of the Silabs devices. SiLabs does offer the EC2 USB interface for target debug in your kit where you would need to purchase some type of JTAG iterface device for the selected ARM chip.
You get a 16/32 bit chip at the 8 bit price with more memory and often higher clock speeds.
Take a look at some of the data sheets linked on this website.
Bradford

Lou, I have had to get used to what has passed above. When you speak to people, phone or face to face, they suddenly become members of the human race.
The days of PLM51 have sadly passed: now there was an elegant and efficient little compiler, but then it was designed by the guys who made the uCs (85, 51, 80, 88, 86/7, 186/7, 286/7, 386/7..... and you could port between them).

If the C bots could get rid of "unsigned character", when they mean "byte", allow base 2 in the source, and get rid of most of the darned braces I would be happy to meet 1/2 way.
As it is C is the only show in town and all things to all men. I have had to learn to accept the compromises.

BTW does anyone know if there is a token I can use to create a NOOP instruction in C51 source code?

Some of what you said went over my head (ie PLM51).

Just an update. I have pretty much completed the project in assembly with maybe 1000 bytes of code (about 1/4 that required by C in my estimation) and it does it's conversion in 100us. This includes 32bit divide and is before I have implemented any optimizing - the code is *** code though that I strung together with my limited knowledge of the limited instruction set of the 8051. That's just my opinion, mind you. Evidently, there are many instructions not available on the 8051 that I found with other MCUs. Oh well.

I aint a pro but when I got a hold of a pdf version of the keil assembly manual via the black market (keil does not know one exists) I felt right at home.

I love assy. But, to be fair, doing the feasibility analysis (first attempt) in C was easy and worthwhile.

If you have 1000 bytes of ASM and 4000 bytes with C
Either you are a master ASM programmer, or a Poor Embedded C programmer. That or are using a poor compiler.

Do not take it Personal. Coding for an a limited memory Embedded System is not the same as for the desk top.
Embedded C programs get large because statements that produce a large amount of code look the same as those that do not.
Like using int as a loop counter (less than 255). You would not use a 16 bit signed value in ASM, but many pepper their C code with it. Printing with printf() that is over a 1K right there. Large Memory model? Click
And on and on.

Yes, it is a shame that Keil has stopped doing the '51 manuals as PDF documents.

:-(

http://www.keil.com/support/man/docs/c51/c51__nop_.htm

Either you are a master ASM programmer, or a Poor Embedded C programmer. That or are using a poor compiler.

Or he forgot to turn on the compiler optimizations, used the wrong memory model, etc. But I guess that would fall under "inexperienced embedded C programmer".

If the C bots could get rid of "unsigned character", when they mean "byte",

typedef unsigned char byte;

allow base 2 in the source,

There are some #define tricks to do something along those lines. Or write your own preprocessor.

and get rid of most of the darned braces I would be happy to meet 1/2 way.

#define { BLOCK_STARTS_HERE
#define } BLOCK_ENDS_HERE

Then again, I don't think this is any better than using braces. ;)

And you can probably write C code without using any more braces than required for enclosing functions in, I think. However, this would probably result in some of the most mindbogglingly convoluted C code that was ever written (since it would require heavy use of gotos, omitting most control structures, etc).

Compound statements ("blocks") are a basic element of structured programming.

The size difference between assembler and C can also come from calling a C RTL that drags in large blocks of library code. This quickly offsets the quota between C and assembler for smaller programs.

The size difference between assembler and C can also come from calling a C RTL that drags in large blocks of library code. This quickly offsets the quota between C and assembler for smaller programs.

Having a look at the list files should make it clear where the C program is burning those extra 3k.

First;
Andy, thanks for the link to the nop info.

Also guys, I take your point about #defining, C does have enough higher level functionality to make it very usable.
I think my overall point is, should a high level language mean you have to remember dozens of tokens and their weird variants? More pertinent, writing effectively for embedded 8bit hardware really does call for a lot of bit twiddling. It is so easy when you can see the binary on the page rather than converting to and from hex on a handy jotter. Less room for error too. I want compact runtime output but I can't see any need for especially compact source code, quite the reverse really. The closer I can get to natural English the better.

Sorry Lou, I'm being nostalgic. PLM was a family of languages designed by Intel for embedded work with their uCs and Ps. Based on IBM's PL/1 mainframe language and very popular in the 70's and 80's.
The code output was phenomenally compact. I wrote 1000s of lines of assembler for the 80188 and 8051. When I started using PLM I was sceptical about efficiency but could rarely improve on the compiler with hand coding. Maybe I'm just a lousy assembly programmer and a grumpy old man.

Good to see a vigorous forum here anyway. I'll shut up now and get back to work.

en.wikipedia.org/.../M

Holy cow, Rob, you're an old relic :-)

I must admit I have never heard of PL/M before you mentioned it - I was not even born when it was conceived...