Re: Compilers

[Eduardo Pereira Habkost <ehabkost@conectiva.com.br>]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

Hi, all,

On Fri, May 28, 2004 at 11:42:38AM +0100, David Given wrote:
<snip>
> 
> I've tried to compare the code produced by cc and bcc. I'm not entirely sure 
> this is a fair comparison because I don't think I managed to invoke bcc's 
> optimiser correctly, but here you go anyway. Fixed-pitch font recommended.
> 
> The source:
> 
> ---snip---
> extern int printf(char* format, ...);
> 
> int fnord(int i)
> {
>         int count = 0;
> 
>         while (i)
>                 count += i--;
>         return count;
> }
> 
> int main(int argc, char* argv[])
> {
>         printf("Hello, world!\n");
>         printf("%d\n", fnord(argc));
>         return 0;
> }
> ---snip---
> 
> The output:
> 

Nice, I would like to compare with the code that gcc-8086 is producing
currently, too. Please note that there could be hiddend bugs that I've
seen yet.  :)

I've used -O3 for compilation:
(GNU as AT&T syntax used)

_fnord:
        push    %bp
        mov     %sp,%bp

        movw    2(%bp),%dx
        movw    $0x0,%ax
        cmpw    $0x0,%dx
        je      .L15
.L13:
        addw    %dx,%ax
        addw    $0xffffffff,%dx
        cmpw    $0x0,%dx
        jne     .L13
.L15:

        leave
        ret

Some things that can be noted: There is not 'dec' instruction, yet. It
can be added. It is using 'leave' for function exit. IIRC, it is a
80186 instruction, so it is better have an option to use is better have
an option for the user choosing to use it or not.

One bug appeared: it is using 2(%bp) for getting the function
parameter. It doesn't look correct.  :)

A -fno-frame-pointer option would be nice, too. I guess that most people
wouldn't want them on ELKS, and it will make code smaller and use less
stack space.

> BCC                             CC
> 
> _fnord:                         _fnord:
> push bp                         push bp
> mov bp,sp                       mov bp,sp
> dec sp                          push si
> dec sp                          xor si,si
> xor ax,ax                       .4:
> mov -2[bp],ax                   cmp 4(bp),#0
> jmp .2                          je .3
> .3:                             mov dx,4(bp)
> mov ax,4[bp]                    mov cx,dx
> dec ax                          dec cx
> mov 4[bp],ax                    mov 4(bp),cx
> inc ax
> add ax,-2[bp]
> mov -2[bp],ax                   add si,dx
> .2:                             
> mov ax,4[bp]                    
> test ax,ax
> jne .3
> .4:
> .1:                             .3:
> mov ax,-2[bp]                   mov ax,si
> mov sp,bp
> pop bp
> ret                             jmp .sret
> 
> The main() function produced by both compilers is identical apart from minor 
> differences: cc likes using pop to do a stack retraction, where bcc does a 
> mov sp,bp instead. This means that cc produces smaller but slower code, but 
> bcc produces faster code. *shrug*
> 
> cc seems to have better register allocation and avoids using stack slots when 
> it doesn't need to. bcc has put the loop conditional at the bottom instead of 
> the top; not sure why, it makes the code larger.
> 
> Given that currently the ELKS kernel is about 70kB of code, a little 
> problematic given the 64kB limit, anything that will make the code smaller is 
> good! Plus, cc is a real ANSI compiler. When I get some spare time I'll see 
> if I can have a look at building the ELKS kernel on Minix. Since the two 
> compilers use the same calling conventions I don't think it would be terribly 
> hard and I'd be interested in seeing what sort of differences there are in 
> real code.
> 
> Incidentally, if you're interested in what ELKS might end up being, I strongly 
> suggest you install a copy of Minix on something. It's fascinating just how 
> usable it is, on such limited hardware.
> 

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]