Message-Id:	<199604301002.GAA13528@delorie.com>
Date:	Tue, 30 Apr 96 12:40:46 LIT
From:	Martynas Kunigelis <martynas DOT kunigelis AT VM DOT KTU DOT LT>
Subject:	Re: register calling conv.
To:	DJGPP mailing list <DJGPP AT delorie DOT com>
In-Reply-To:	Your message of Mon, 29 Apr 1996 12:36:33 +0000

On Mon, 29 Apr 1996 12:36:33 +0000 you said:
>>
>> Maybe... but how do I force DJGPP to use register calling convention?
>
>I see no advantage to this because of the limited number of registers
>on the x86 architecture.  Even if you pass parameters in registers
>the compiler will most likely still produce pushes and pops because
>there are many x86 instructions that absolutly require register
>parameters.  Therefore I see no net gain.
>
>-Kevin

I've actually spent a lot of time and effort studying the subject. I am
working on a `fastcall' feature for DJGPP, I've already hacked GCC to
have a __fastcall__ function attribute and a -mfastcall switch. The thing
left is to adopt and recompile the libc.a and other standard libraries.
The `fastcall' thing implies that the function is called with 3 first
integer (or short or char) parameters in EAX, EDX and ECX respectively and
it cleans up the stack used to pass other (fourth and so on) parameters
with a `ret <adjustment>' instruction. Actually you could get the same
results with __attribute__ ((__regparm__(3), __stdcall__)), but GCC currently
has a bug, which makes it take only the LAST attribute specified into account.
Thus, you can assign only ONE attribute to a function, and my hack solves
this (__attribute__ ((__fastcall__)) ). On the other hand, -mfastcall is
exactly the same as -mregparm=3 and -mrtd, but why type extra stuff? From
now on, one more thing bothers me: IS IT WORTH IT??? I mean, x86 has really
few registers, and large functions would still need to save the parameters
passed in memory.. I now need an opinion from an expert.
 Anyway, if someone is interested in patches for GCC or precompiled binaries
for cc1 and cc1plus with the `fascall' capability, drop me a note.

now something completely different: Eli, the FAQ says, that OS/2 Warp *maybe*
forbids a fat DS (i.e. with a 4GB limit). I hereby state: I does *not*. The
FAQ also says Linux does. Really? Anyone running Linux? DJ? I mean, Watcom
compiles shouldn't run under Linux'es DosEmu then. Do they? Ah, something
more: could somebody running Linux mail me two files:
/usr/include/elf.h and /usr/include/linux/elf.h ? TIA.

and to continue the ELF thread: I know ELF allows to generate PIC (position
independent code). But why not create relocatable executables? That's no
speed loss, like in PIC case. Or maybe ELF allows relocation too? Anyone
has enough knowledge on that? I mean with relocatable executables it is
possible to have program's base address 0, and then near pointers stuff
becomes really trivial: char *screen = (char *) 0xa0000; Or maybe this
also isn't worth it?

PS: I understand that implementing this approach in DJGPP is somewhat
impossible, it would take a 100% near pointer based system, but my interest
is, say, theoretical.. ;-)


Ahhh... Thank you for listening! :))

Martynas

- Raw text -