Etienne Lorrain wrote:
>
> The only time I ever needed this "end line recalculation" was when the
> heigh in
> graphic lines was not a multiple of the character heigh - i.e. 640x350 with
> 8x16
> or 8x8 chars - some VGA adapters do not hide the bottom graphic lines.
> The function vga_set_
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >> - The VGA recalc has the same bug as the assembly version where a VGA
> >> write protected register is written (Overflow register) without setting
> >> the enable bit (see VGA docs).
>
> I dug into this, and it turns out you're incorrect. Both
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > "mov %fs:(%ebx,%eax,4),%ecx" works for me.
>
> That's an example on what "m" can generate.
>
> "g" could produce stuff like:
>
> mov %fs:$1234,%ecx
> mov %fs:%eax,%ecx
My solution was to use %fs:%a1 inst
Etienne Lorrain wrote:
> BUGS: some implementations (including the original IBM PC) have a bug which
> destroys BP
> the Trident TVGA8900CL (BIOS dated 1992/9/8) clears DS to h when
> scrolling in an SVGA mode (800x600 or higher)
"When scrolling in an SVGA mode", sounds
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> - Does not save and restore %ds when printing a char on the screen (%ds
> is
> destroyed only when the content of the screen scroll - only for some
> video cards)
> >> %ds? Aren't you confusing it with the old bug which woul
I tested the 'x86 setup code rewrite revised' patches on a few new
Pentium systems and some virtualized environments without any issues.
Here are some further patches ontop of yours to remove some unused
code and ifdef the MCA setup.
-Andrew
-
To unsubscribe from this list: send the line "unsub
On Fri, 13 Jul 2007, Etienne Lorrain wrote:
>
> > >> Also, I do not know if "m" is right in here:
> > >> static inline u8 rdfs8(addr_t addr)
> > >> {
> > >> u8 v;
> > >> asm("movb %%fs:%1,%0" : "=r" (v) : "m" (*(u8 *)addr));
> > >> return v;
> > >> }
> >
> > The "m" is correct right there.
>
Chris Smith wrote:
> On 7/10/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> So far our effort at getting paid staff seems to have fallen through :(
>>
>>-hpa
>
> Presumably the 501c status hasn't changed since OLS?
> If a paid position isn't forthcoming, perhaps there can be a bounty
> s
Chuck Ebbert wrote:
>> - The VGA recalc has the same bug as the assembly version where a VGA write
>> protected
>>register is written (Overflow register) without setting the enable bit
>> (see VGA docs).
I dug into this, and it turns out you're incorrect. Both the assembly
code and the C c
Etienne Lorrain wrote:
> --- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
>> Chuck Ebbert wrote:
>
> Wrong name.
>
Have fun, this code:
- do not open the fast A20 gate before checking if the slow A20 gate is
open or
>> closed.
>>
>> As does the current code; this is highly inte
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Chuck Ebbert wrote:
Wrong name.
> >> Have fun, this code:
> >> - do not open the fast A20 gate before checking if the slow A20 gate is
> >> open or
> closed.
>
> As does the current code; this is highly intentional behaviour since
> there ar
Chuck Ebbert wrote:
>> Have fun, this code:
>> - do not open the fast A20 gate before checking if the slow A20 gate is
>> open or closed.
As does the current code; this is highly intentional behaviour since
there are machines (in particular a whole series of machines made by
Olivetti) which loc
On 07/13/2007 10:25 AM, Etienne Lorrain wrote:
[ Added back cc:'s]
> On Thu, 12 Jul 2007, Linus Torvalds wrote:
>> On Thu, 12 Jul 2007, Andrew Morton wrote:
>>> This code has been in -mm since 11 May, as git-newsetup.patch. It has
>>> caused (for what it is) astonishingly few problems. Maybe a
Andi wrote:
> The only thing questionable is that .code16gcc is arguably quite
> an abuse of gcc. I even checked with some gcc developers
> and they weren't too happy about it. e.g. it's not regression
> tested at all so we would be basically on our own with it.
On the other hand GCC just produc
On Thu, 12 Jul 2007, Linus Torvalds wrote:
> On Thu, 12 Jul 2007, Andrew Morton wrote:
> >
> > This code has been in -mm since 11 May, as git-newsetup.patch. It has
> > caused (for what it is) astonishingly few problems. Maybe a couple of
> > build glitches and one runtime failure, all quickly f
On Thu, Jul 12, 2007 at 10:24:48AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> >
> > This patch set replaces the x86 setup code, which is currently all in
> > assembly, with a version written in C, using the ".code16gcc" feature
> > of binutils (which has been
On Thu, 12 Jul 2007, Andrew Morton wrote:
>
> This code has been in -mm since 11 May, as git-newsetup.patch. It has
> caused (for what it is) astonishingly few problems. Maybe a couple of
> build glitches and one runtime failure, all quickly fixed.
>
> I'd say it's ready.
Ok. That makes it e
On Thu, 12 Jul 2007 10:24:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> >
> > This patch set replaces the x86 setup code, which is currently all in
> > assembly, with a version written in C, using the ".code16gcc" feature
> > of binut
On Wed, 11 Jul 2007, H. Peter Anvin wrote:
>
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
>
> 76 files changed, 4606 insertions(+), 5209
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
".code16gcc" is useable since a bit earlier than that, in fact since:
http://sourceware.org/m
Jeff Garzik wrote:
>
> I'm sure you know what's changed since the last revision, but nobody
> everybody does :) It would be nice to know what's different from the
> last posting.
>
- Added -fno-toplevel-reorder/-fno-unit-at-a-time to the Makefile; this
is necessary for .code16gcc to be safe o
H. Peter Anvin wrote:
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be not
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be noted that I found a fair n
On 7/10/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
So far our effort at getting paid staff seems to have fallen through :(
-hpa
Presumably the 501c status hasn't changed since OLS?
If a paid position isn't forthcoming, perhaps there can be a bounty
system for people to contribute $ t
Randy Dunlap wrote:
>
> Too bad, not just for x86-newsetup but lots of other gits as well.
>
Well, it's a function of gitweb, but we have been forced to disable it
because it interferes hideously with the caching system. We'll
hopefully eventually get around to fixing it, but it's not a high
pr
On Tue, Jul 10, 2007 at 02:13:50PM -0700, H. Peter Anvin wrote:
> Al Boldi wrote:
> >
> >> There is a git tree on git.kernel.org you can pull, which is current
> >> against 2.6.22.
> >
> > How can I pull a tar-ball from that without using a git client?
> >
>
> I don't think you can.
gitweb has
On Tue, 10 Jul 2007 14:13:50 -0700 H. Peter Anvin wrote:
> Al Boldi wrote:
> >
> >> There is a git tree on git.kernel.org you can pull, which is current
> >> against 2.6.22.
> >
> > How can I pull a tar-ball from that without using a git client?
> >
>
> I don't think you can.
Too bad, not jus
Al Boldi wrote:
>
>> There is a git tree on git.kernel.org you can pull, which is current
>> against 2.6.22.
>
> How can I pull a tar-ball from that without using a git client?
>
I don't think you can.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
H. Peter Anvin wrote:
> Al Boldi wrote:
> > H. Peter Anvin wrote:
> >> This patch set replaces the x86 setup code, which is currently all in
> >> assembly, with a version written in C, using the ".code16gcc" feature
> >> of binutils (which has been present since at least 2001.)
> >>
> >> The new co
Al Boldi wrote:
> H. Peter Anvin wrote:
>> This patch set replaces the x86 setup code, which is currently all in
>> assembly, with a version written in C, using the ".code16gcc" feature
>> of binutils (which has been present since at least 2001.)
>>
>> The new code is vastly easier to read, and, I
H. Peter Anvin wrote:
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
>
> The new code is vastly easier to read, and, I hope, debug. It should
H. Peter Anvin wrote:
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be not
H. Peter Anvin wrote:
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be not
Yinghai Lu wrote:
is possible to put 16bit c in seperate directory. or rename them with
_16.c?
They *ARE* in a separate directory, specifically arch/i386/boot. All
the *.c files in there are 16 bits; the 32-bit code is in
arch/i386/boot/compressed or arch/i386/kernel.
-hpa
-
To u
On 7/9/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be noted that I found a fair n
36 matches
Mail list logo
