lkml.org 
[lkml]   [1998]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: VFS 64-bit clean? Not yet (was Re: large-file-system)


On Mon, 16 Feb 1998, Alan Cox wrote:
>
> > Sure, the 64-bit version may _look_ simpler to do, but if you actually
> > try to optimize it for performance you'll wish you hadn't gone to "long
> > long". And the page cache is timing critical.
>
> 64bits is what folks will expect, and with things like lseek you dont need
> a paticularly huge disk to create file using bit63 in its file offsets. If
> long long is so bad maybe the right answer is to ask the egcs people to
> look into it - and yes Im aware gcc on the whole writes crud code for
> any case where sizeof(register) < sizeof(object). Its what makes gcc
> so weak for embedded work.

I'd certainly like to see egcs improve "long long" handling, but I think
that on the x86 the problem is twofold. The long long handling is just
plain bad, and that's probably the easiest one to fix up with some md file
updates. But the worse problem is probably bad register handling in gcc,
both for normal registers and for "eflags".

For example, a lot of the long long things are really _five_ register
inputs: two source registers, two source-dest registers, and eflags to
keep track of the carry bit. That means that you have four registers (out
of eight) just for data - something that gcc isn't too good at anyway, but
you also have the added constraint that you must keep the right eflags
updates: and gcc-x86 doesn't seem to track eflags at all (it has various
"magic" eflags rules, but gcc doesn't actually seem to consider eflags to
be a real register, so it can't actually schedule any of the code very
well).

Maybe egcs is better at handling eflags on x86, but I'd really like to
think that we have a stable compiler first, rather than trusting a known
bad compiler (yes, gcc is actually known for having generated not only
slow but actually buggy code for "long long").

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.075 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site