2001-04-17 21:29:34

by Pavel Machek

[permalink] [raw]
Subject: i386 cleanups

Hi!

These are tiny cleanups you might like. sizes are "logically"
long. No, it does not matter on i386.

processor.h makes INIT_TSS look much more readable. [Please tell me
applied or rejected]

Pavel

Index: include/asm-i386/posix_types.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 posix_types.h
--- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1
+++ include/asm-i386/posix_types.h 2001/02/13 13:49:18
@@ -16,9 +16,9 @@
typedef unsigned short __kernel_ipc_pid_t;
typedef unsigned short __kernel_uid_t;
typedef unsigned short __kernel_gid_t;
-typedef unsigned int __kernel_size_t;
-typedef int __kernel_ssize_t;
-typedef int __kernel_ptrdiff_t;
+typedef unsigned long __kernel_size_t;
+typedef long __kernel_ssize_t;
+typedef long __kernel_ptrdiff_t;
typedef long __kernel_time_t;
typedef long __kernel_suseconds_t;
typedef long __kernel_clock_t;
Index: include/asm-i386/processor.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-i386/processor.h,v
retrieving revision 1.2
diff -u -u -r1.2 processor.h
--- include/asm-i386/processor.h 2000/09/12 21:27:18 1.2
+++ include/asm-i386/processor.h 2001/02/13 13:49:22
@@ -365,19 +365,11 @@
{ &init_mm, 0, 0, NULL, PAGE_SHARED, VM_READ | VM_WRITE | VM_EXEC, 1, NULL, NULL }

#define INIT_TSS { \
- 0,0, /* back_link, __blh */ \
- sizeof(init_stack) + (long) &init_stack, /* esp0 */ \
- __KERNEL_DS, 0, /* ss0 */ \
- 0,0,0,0,0,0, /* stack1, stack2 */ \
- 0, /* cr3 */ \
- 0,0, /* eip,eflags */ \
- 0,0,0,0, /* eax,ecx,edx,ebx */ \
- 0,0,0,0, /* esp,ebp,esi,edi */ \
- 0,0,0,0,0,0, /* es,cs,ss */ \
- 0,0,0,0,0,0, /* ds,fs,gs */ \
- __LDT(0),0, /* ldt */ \
- 0, INVALID_IO_BITMAP_OFFSET, /* tace, bitmap */ \
- {~0, } /* ioperm */ \
+ esp0: sizeof(init_stack) + (long) &init_stack, \
+ ss0: __KERNEL_DS, \
+ ldt: __LDT(0), \
+ bitmap: INVALID_IO_BITMAP_OFFSET, \
+ ioperm: {~0, } \
}

#define start_thread(regs, new_eip, new_esp) do { \


--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]


2001-04-17 22:57:57

by Jeff Garzik

[permalink] [raw]
Subject: Re: i386 cleanups

Pavel Machek wrote:
>
> Hi!
>
> These are tiny cleanups you might like. sizes are "logically"
> long. No, it does not matter on i386.
>
> processor.h makes INIT_TSS look much more readable. [Please tell me
> applied or rejected]
>
> Pavel
>
> Index: include/asm-i386/posix_types.h
> ===================================================================
> RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v
> retrieving revision 1.1.1.1
> diff -u -u -r1.1.1.1 posix_types.h
> --- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1
> +++ include/asm-i386/posix_types.h 2001/02/13 13:49:18
> @@ -16,9 +16,9 @@
> typedef unsigned short __kernel_ipc_pid_t;
> typedef unsigned short __kernel_uid_t;
> typedef unsigned short __kernel_gid_t;
> -typedef unsigned int __kernel_size_t;
> -typedef int __kernel_ssize_t;
> -typedef int __kernel_ptrdiff_t;
> +typedef unsigned long __kernel_size_t;
> +typedef long __kernel_ssize_t;
> +typedef long __kernel_ptrdiff_t;

If it doesn't matter on i386 why bother?


> #define INIT_TSS { \
> - 0,0, /* back_link, __blh */ \
> - sizeof(init_stack) + (long) &init_stack, /* esp0 */ \
> - __KERNEL_DS, 0, /* ss0 */ \
> - 0,0,0,0,0,0, /* stack1, stack2 */ \
> - 0, /* cr3 */ \
> - 0,0, /* eip,eflags */ \
> - 0,0,0,0, /* eax,ecx,edx,ebx */ \
> - 0,0,0,0, /* esp,ebp,esi,edi */ \
> - 0,0,0,0,0,0, /* es,cs,ss */ \
> - 0,0,0,0,0,0, /* ds,fs,gs */ \
> - __LDT(0),0, /* ldt */ \
> - 0, INVALID_IO_BITMAP_OFFSET, /* tace, bitmap */ \
> - {~0, } /* ioperm */ \
> + esp0: sizeof(init_stack) + (long) &init_stack, \
> + ss0: __KERNEL_DS, \
> + ldt: __LDT(0), \
> + bitmap: INVALID_IO_BITMAP_OFFSET, \
> + ioperm: {~0, } \

IIRC certain key structures cannot be taken to gcc's style of struct
initialization, and IIRC this is one of them. Maybe that's a egcs-1.1.2
bug. Have you looked at the assembly output to make sure things are
100% ok after this change?

Regards,
Jeff, who wonders if there is a way to upgrade human memory as easily as
computer memory...


--
Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a
Building 1024 | man to fish, and a US Navy submarine will make sure
MandrakeSoft | he's never hungry again." -- Chris Neufeld

2001-04-18 09:11:17

by Abramo Bagnara

[permalink] [raw]
Subject: Re: i386 cleanups

Jeff Garzik wrote:
>
> Pavel Machek wrote:
> >
> > Hi!
> >
> > These are tiny cleanups you might like. sizes are "logically"
> > long. No, it does not matter on i386.
> >
> > processor.h makes INIT_TSS look much more readable. [Please tell me
> > applied or rejected]
> >
> > Pavel
> >
> > Index: include/asm-i386/posix_types.h
> > ===================================================================
> > RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v
> > retrieving revision 1.1.1.1
> > diff -u -u -r1.1.1.1 posix_types.h
> > --- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1
> > +++ include/asm-i386/posix_types.h 2001/02/13 13:49:18
> > @@ -16,9 +16,9 @@
> > typedef unsigned short __kernel_ipc_pid_t;
> > typedef unsigned short __kernel_uid_t;
> > typedef unsigned short __kernel_gid_t;
> > -typedef unsigned int __kernel_size_t;
> > -typedef int __kernel_ssize_t;
> > -typedef int __kernel_ptrdiff_t;
> > +typedef unsigned long __kernel_size_t;
> > +typedef long __kernel_ssize_t;
> > +typedef long __kernel_ptrdiff_t;
>
> If it doesn't matter on i386 why bother?

It helps with printf %-formats to avoid some arch specific warnings.


--
Abramo Bagnara mailto:[email protected]

Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org
It sounds good!

2001-04-18 17:10:03

by Linus Torvalds

[permalink] [raw]
Subject: Re: i386 cleanups



On Tue, 17 Apr 2001, Pavel Machek wrote:
>
> These are tiny cleanups you might like. sizes are "logically"
> long.

No. Sizes are not "logical". They are whatever you decide they are, ie
it's purely a complier convention.

At least earlier, size_t was defined as "unsigned int" in user mode, and
doing anything else would make gcc complain about clashes with its
compiled-in __builtin_size_t that it uses for the builtin prototypes (ie
if you had a declaration for "void *memcpy(void *dest, const void *src,
size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get
a "redefined with different arguments" warning or something).

Linus

2001-04-18 22:02:20

by Michael Meissner

[permalink] [raw]
Subject: Re: i386 cleanups

On Tue, Apr 17, 2001 at 02:46:09PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 17 Apr 2001, Pavel Machek wrote:
> >
> > These are tiny cleanups you might like. sizes are "logically"
> > long.
>
> No. Sizes are not "logical". They are whatever you decide they are, ie
> it's purely a complier convention.

Not purely a compiler convention, but an ABI requirement. In particular, Linux
GCC adheres to the ABI specified in the System V UNIX Intel386 (tm) Processor
Supplement, and on page 6-66, in figure 6-70, the specification for stddef.h
says that:

typedef int ptrdiff_t;
typedef unsigned int size_t;
typedef long wchar_t;

> At least earlier, size_t was defined as "unsigned int" in user mode, and
> doing anything else would make gcc complain about clashes with its
> compiled-in __builtin_size_t that it uses for the builtin prototypes (ie
> if you had a declaration for "void *memcpy(void *dest, const void *src,
> size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get
> a "redefined with different arguments" warning or something).

While, I grant that this is one area the ABI could have been improved upon
(alignment of floating point, and reservation of EBX as GOT pointers are other
sore spots), it is the ABI of record. Yes, we could certainly choose a
different ABI for Linux, but it is probably too late for that in the case of
the x86.

--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [email protected] phone: +1 978-486-9304
Non-work: [email protected] fax: +1 978-692-4482