Karim BELABAS on Wed, 5 Mar 2003 00:19:00 +0100 (MET)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: linker warning


On Tue, 4 Mar 2003, Ilya Zakharevich wrote:
> On Tue, Mar 04, 2003 at 04:51:28PM +0100, Karim BELABAS wrote:
> > It's a terrible mess. I started to rationalize this by removing the worst
> > hacks first (sparc). I'm not claiming the current situation is satisfactory.
> > All the more as it seems I've forgotten a case, and hiremainder may not be
> > defined [ cf Ilya's and Igor's bug reports ].
>
> Now when hiremainder and friends are never in a register, why not take
> them via a pointer supplied to the assembler routines?  I do not see
> how this can make a difference (IIUC, this is a pointer on stack
> instead of a pointer in the code segment).
>
> This would remove the need for globals at all.

If CC = gcc, all the micro kernel is macroified [ about 20% faster ].
This doesn't mix well with pointers [ without adding extra ugliness ]

Note that with  conventional build environments (gcc:-), they are not really
globals, only used as

// no assembler kernel; same things exist with asm() statements
#define LOCAL_HIREMAINDER ulong hiremainder
#define divll(a,b) ({    \
  ulong __q, __r         \
  ...
  hiremainder = __r;     \
  __q;                   \
})

blah()
{
  ulong q, r;
  LOCAL_HIREMAINDER;

  hiremainder = 0;
  q = divll(a, b);
  r = hiremainder;
}

One of the reasons why this ugly hack exist is that a single C construct had
to take care of the zillion different ways in which the kernel could be
implemented across all architectures and build system [ including the huge
hardcoded m86k assembler kernel ]. This is all done via (over-)complicated
#define. It's not trivial to change the interfaces...

I'm currently trying to restrict the kernel as much as I can, and remove all
code duplication here. Then we might contemplate an interface change.
Ideally, the portable kernel should be good enough to remove most of the
large assembler pieces emulating lacking hardware division [ and which I
suspect are slower than the portable kernel ]


I've only played with the division so far, since it's the one I'm having
trouble with in the SuperSparc assembler. It's quite fun :-)

current CVS: [ on ix86 + gcc, forcing portable kernel ]
kernel=none
+++ Total bench for gp-sta is 1720
+++ Total bench for gp-dyn is 1740

kernel=none + new (portable) divll.h (CC = any ANSI C compiler)
+++ Total bench for gp-sta is 1680
+++ Total bench for gp-dyn is 1670

kernel=none + new macroified (portable) divll.h (need CC = gcc)
+++ Total bench for gp-sta is 1550
+++ Total bench for gp-dyn is 1566


On this machine, the best kernel [ as far as the bench goes, this is native
ix86 kernel. Beats gmp kernel ] currently yields
+++ Total bench for gp-sta is 1072
+++ Total bench for gp-dyn is 1096

Cheers,

    Karim.
-- 
Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dép. de Mathématiques, Bât. 425   Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud              http://www.math.u-psud.fr/~belabas/
F-91405 Orsay (France)            http://www.parigp-home.de/  [PARI/GP]