What micros do you actually hate to work with?

By the way, 12 instructions on the x86 and this assuming that the values are passed _on a software stack_ and I take the trouble to deal with it. You can cut that to 10, otherwise.

Jon

In case it isn't clear to others, though, both Isaac's VS.NET example and the one I am imagining assume parameters passed on the x86 stack. This isn't always a necessary approach, as compilers may certainly define the case where a certain small number of parameters can be passed in registers and only spilled to memory if addresses need to be taken. However, I am comparing apples to apples with the 21 byte figure here. Both Isaac's and my example assume parameters passed on the stack. My code would be shorter still, otherwise.

Jon

Yup that is correct. By default C compilers on the x86 use the STDCALL convention I believe. In this case the parameters are pushed on the stack in the opposite order they appear on the C func prototype.

There is a FASTCALL convention which I believe uses registers. I might try it out on the compiler and see what it does. I will post again if I get anything different.

-Isaac

; _a$ = ecx ; _b$ = edx ; Line 276 mov eax, ecx ; Line 299 test eax, eax jne SHORT $L1047 test edx, edx jne SHORT $L1054 ; Line 300 mov eax, 1 ; Line 320 ret 0 $L1047: ; Line 303 test edx, edx ; Line 304 je SHORT $L1046 ; Line 309 cmp eax, edx je SHORT $L1054 $L1096: ; Line 311 jae SHORT $L1055 ; Line 312 sub edx, eax ; Line 313 jmp SHORT $L1056 $L1055: ; Line 314 sub eax, edx $L1056: ; Line 309 cmp eax, edx jne SHORT $L1096 $L1054: ; Line 318 mov eax, edx $L1046: ; Line 320 ret 0

I think they could have used a conditional move instruction that later CPU's have. I set the target CPU to the Pentium II/III to see if it will use it but it didnt. I think its safe to say that it is still longer than yours.

-Isaac

Yes, that is pretty much what you'd expect from a decent compiler. It should be able to move the returns up automatically as you did you hand though. Did you also change the final "return b" into "return a", or did GCC do that optimization? Pretty good if it did.

For minimum size you can do better by removing most of the special cases and always using the main loop. The special cases can either be handled at the beginning, or at the end:

unsigned int gcd1 (unsigned int a, unsigned int b) { if (a == 0 && (a = b) == 0) a++; do { if (a > b) a -= b, b += a; b -= a; } while (b != 0); return a; }

unsigned int gcd2 (unsigned int a, unsigned int b) { do { if (a

I'll try and find some time to do it. The topology I've used before may change, depending on what I see and think about. Not sure if it will be today. But I will put some time into it.

Meanwhile, I could post the x86 version to show it there. Actually a number of them.

Jon

Here's GCC's Thumb version, somewhat longer than yours.

Can you produce the GCC version for the x86? Sorry to ask twice, but I'm interested and it would take me less time to compare, for now.

Jon

Yes - I can, but it takes some time. The GCC on a Mac does not produce x86 code, I have to switch computers.

That's a left shift by 1, and some byte shuffling.

To be honest, I'd probably have skipped the eor trick and rather used a few more registers unless I needed particularly optimised code, but I'd definitely make use of the "swap" instruction.

I've had cases when I needed a few extra bytes of code to fix a bug or add a feature, and it's taken ages to find a good way to compact the code to save those few bytes code space or bits of ram. Of course, it would be much easier to change microcontroller (and probably programming language), but sometimes you have to squeeze just that little bit more out of an existing system.

gcc has built-in functions for that. In particular, the function long __builtin_expect(long exp, long c) returns exp, but tells the compiler that "exp" will probably be "c". So you can write something like:

if (__builtin_expect(x > 0, 1)) { // Do this for (x > 0), which is the normal case } else { // The less usual case }

Of course, compilers for targets that support static branch prediction and other complications can figure out common cases automatically (such as in most loops).

I have never tried __builtin_expect in practice - on most small micros, knowing the most frequent path of a conditional is seldom useful, and gcc does not support the PIC.

Hi guys,

I have the GCC code output here. I compiled it using computers at school (Fedora Core 5 w/ GCC 4.1.0):

Keep in mind that this deviates from the standard Intel syntax ,moves to the 68000 kind of syntax, in that the destination register now the

-Isaac

Here's it. This seems to be somewhat shorter than the competing compilation of Isaac.

----

----

When reading the code, please note that the GNU assembler shows the command arguments in different order than the original Intel spec: the first argument is source and second argument is destination.

movl $1,%ecx

loads the constant 0x00000001 to register ECX.

Tauno Voipio tauno voipio (at) iki fi

What do you get when optimizing for size (GCC and VS)? Optimizing for speed on x86 can produce rather verbose code.

-a

Did you use -fomit-frame-pointer? It adds 5 redundant instructions, or 20% overhead. It's this kind of thing that gives compilers a bad name...

Wilco

I know Paul Hiesh has a 11 instruction version, but it's possible to get it down to 10. I guess that is the optimum.

If you want to go smaller still you need to change the algorithm - making gcd(0,0) return 0 saves a further 2 instructions.

Wilco

OK - here's without frame pointer and optimized for size (-Os):

----

----

The listing was produced with

gcc -c -Os -fomit-frame-pointer -Wa,-ahlms=gcd.lst gcd.c

and editing the directive and empty lines off the listing.

---

Here, an assembler programmer could shorten the code:

- swap %eax and %ecx in the whole module, so the last movl can be left out,

- substitute xchgl %eax,%edx for line 22 and leave lines 23, 24 and 27 out,

- line 30 can use xchgl %eax,%ecx instead, for a saving of 1 byte.

--

Tauno Voipio tauno voipio (at) iki fi

Here is the output of VS .NET optimized for size. I will test for GCC a bit later. Shorter code:

Again not to confuse anyone, this is Intel syntax (dest, src)

-Isaac

After this discussion of what projects fit into 1K using a HLL, on as Microcontroller, here is the newest devices pitched at

So, as you can see, it will not matter if your C code is 1.2K, and your ASM code might be 890 bytes....!!

At first glance they do not look cheap, but the mention of HV IO and "The new devices support a maximum power supply of 33 V with all specifications applying over the range of 3.5 V to 18 V " - have me wondering if that means what it says ?

-jg