To a lot of embedded people, "an order of magnitude" means 2x.
To a lot of embedded people, "an order of magnitude" means 2x.
-- Grant Edwards grante Yow! MMM-MM!! So THIS is at BIO-NEBULATION! visi.com
snipped-for-privacy@c30g2000hsa.googlegroups.com...
elowing
rThe architecture differences wouldnt have made much difference in the case I cited. In fact the original chip would easily have beat the pic had I wrote it in assembly.
Now why would you do that? Seems you allready know there is a big improvement.
As I said, If you want to put it to the test your welcome to try.
PICs are allmost RISC, veryone I know thinks their horrible to write for.
I'll have to take your word for that, thats 1 ARM for every 2 people on the planet (aside from the 4 arms they allready got) I'll look forward to getting mine.
what is the yearly volume of say 8051 or PIC?
???? The order of magnitude means times 0x10, i.e.
messagenews: snipped-for-privacy@c30g2000hsa.googlegroups.com...
That (older) PICs are horrible to write for is generally known, but that doesn't say anything about RISC in general.
Chances are that you already own one (or more) if you have a broadband modem, router, digital camera, printer, settop box, mobile phone, MP3/4 player, PDA, GPS...etc.
It took a while for that to kick in. I don't know whether you deserve a brickbat or a bouquet :)
Thanks
Robert
-- Posted via a free Usenet account from http://www.teranews.com
Probably both. I'm actually serious though. If you're used to working at a low level (e.gl address decoding logic, memory arrays, instruction sets, etc.), then you spend a lot of time thinking about the binary representation of things. "An order of magnitude" to me means one digit more or one digit less. When everything is really binary, each digit is a power of two.
Binary is the only natural base when dicusssing computer stuff. The choice of another base besides binary is purely arbitrary and it could just as easily be 64 or 60 as it could be 10 or 16 or 8.
-- Grant
A real test is to recode the 1.5k asm in C so it is algorithmically identical in C and how the compiler would generate the code. Compare that to the 1.5K PIC implementation in asm.
Regards,
-- Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751
Ok, that sounds nice. Although even nicer would be to have C compiler that would detcted fixed-point (linear, quadratic, cubic, whatever) interpolation, and utilize the instruction set of the target accordinly. This might be difficult though..
-- Jyrki Saarinen http://koti.welho.com/jsaari88/
You are replying to a wrong person. The original poster claimed, that he could get an order of magnitude improvement in performance, by programming the same stuff in assembly vs. C.
-- Jyrki Saarinen http://koti.welho.com/jsaari88/
This haven't been the case for a long time any more.
-- Jyrki Saarinen http://koti.welho.com/jsaari88/
One question: in the context of this newsgroup, how often is it that C compilers support C99. gcc does it, but what about the others.
-- Jyrki Saarinen http://koti.welho.com/jsaari88/
To most normal people, an order of magnitude is a factor of 10.
-- Chuck F (cbfalconer at maineline dot net) Try the download section.
Some more C and C++ optimization techniques are described in:
-- EventStudio -
I've seen 2x in the context of "on the close order" or "to a close order of magnitude" but yes, the expectation of the unadorned phrase is a factor of ten.
Remember that in binary, an order of magnitude is only a factor of two :-)
Many high-end C compilers (it's certainly the case with gcc and Diab Data - I don't know the details of other compilers) can integrate inline assembly with their optimisers, allowing the assembly code to be moved around and to share common registers with C code.
While I agree that in general, a decent C compiler will be close to or better than many assembler programmers (depending on the programmer, the target cpu, and the compiler), there are times when assembly will give better code simply because C has no support for the concepts in question. Bit manipulation code involving rotations or clever use of carry and overflow flags, for example, are often clearer and faster in assembly. I know that some compilers give direct access to these features at the C level (through pseudo-variables of some sort), but what you are then writing is practically assembly anyway, just with C grammar.
Whether it is worth the effort using assembly (or assembly-with-C-grammar) is highly dependant on the case in question, of course.
Rubbish. It is very common for compilers to use some sort of table for implementing switches, so there is normally no benefit in having the most frequent cases first. Many compilers will generate better code if the cases are in numerical order, and different ordering of the cases may improve code sharing between the cases. If you have significantly more common cases, pull them out first with if's before the general switch.
Assembly is occasionally useful in C, but modern compilers and modern cpus have greatly reduced the need for assembly for pure speed purposes.
The "register" keyword went the way of the dodo some ten years ago - any serious compiler will ignore it and put local variables in registers anyway.
This is true enough, at least for some functions - avoiding the printf family is often a good idea. But again, it's a lot better now than it used to be - libraries regularly come with a number of printf implementations such as versions without floating point support.
Do you mean
10 base 2 = 2 base 10or
10 base 10 = 1010 base 2 ?Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
The register keyword gives a hint that the compiler should allocate the given variable to a register. Different architectures have a different number of available registers. So, it is recommended to avoid using register and one should rely on the compiler's normal register allocation routine. Different compilers treat this in different ways.
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.