On Wed, 17 Jan 2001, Garrett Wollman wrote:
> < said:
>
> > Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'?
> > add longword, add longword with carry? I know it would be pretty
> > ugly, but it should work, no?
>
> The two bus cycles are independent, so there is a race cond
On 2001-Jan-17 10:28:03 -0800, John Baldwin <[EMAIL PROTECTED]> wrote:
> So as long as we keep all
>atomically-accessed 64-bit integers within a single page we should be fine for
>CX8 on all pentiums should we even want 64-bit atomic ops.
This comes free of charge (along with better performance)
< said:
> There are SMP machines using both 386 and 486 processors. There is
> no support in FreeBSD for SMP on pre-Pentium processors.
Yes, I well recall the Sequent. I wish for it to remain a memory.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curr
On 2001-Jan-17 10:43:10 -0500, Garrett Wollman <[EMAIL PROTECTED]> wrote:
>< said:
>
>> To support multiple masters, you need proper locks.
>
>On older processors, yes. On processors with the CX8 feature bit set,
>you can do it without any sort of locking (indeed, this is a primitive
>that semaph
< said:
> person was referring to: on Pentiums with stepping < 0xc, a cmpxchg8b that
> crosses a page boundary triggers an illegel opcode fault rather than a page
> fault if the second page is missing.
This is (part of) the famous `F00F bug'.
-GAWollman
To Unsubscribe: send mail to [EMAIL P
On 17-Jan-01 Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Robert Drehmel writes:
>>In <[EMAIL PROTECTED]>, John Baldwin wrote:
>>> Early Pentiums (<= P90) don't support CX8 or so I've heard, which make this
>>> slightly more complicated, as for a pentium we would have to use a funct
In message <[EMAIL PROTECTED]>, Robert Drehmel writes:
>In <[EMAIL PROTECTED]>, John Baldwin wrote:
>> Early Pentiums (<= P90) don't support CX8 or so I've heard, which make this
>> slightly more complicated, as for a pentium we would have to use a function
>> pointer that we setup during probe.
In <[EMAIL PROTECTED]>, John Baldwin wrote:
> Early Pentiums (<= P90) don't support CX8 or so I've heard, which make this
> slightly more complicated, as for a pentium we would have to use a function
> pointer that we setup during probe. Also, during a SMP boot we would have to
> panic if CX8 was
On 17-Jan-01 Garrett Wollman wrote:
> < <[EMAIL PROTECTED]> said:
>
>> To support multiple masters, you need proper locks.
>
> On older processors, yes. On processors with the CX8 feature bit set,
> you can do it without any sort of locking (indeed, this is a primitive
> that semaphores can be
< said:
> Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'?
> add longword, add longword with carry? I know it would be pretty
> ugly, but it should work, no?
The two bus cycles are independent, so there is a race condition.
OTOH, it's a fairly *unlikely* race condition, and
< said:
> To support multiple masters, you need proper locks.
On older processors, yes. On processors with the CX8 feature bit set,
you can do it without any sort of locking (indeed, this is a primitive
that semaphores can be built upon). Consider the following:
atomic_increment:
; pr
On 2001-Jan-16 19:10:10 -0800, Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>* Bruce Evans <[EMAIL PROTECTED]> [010116 19:03] wrote:
>> These don't use atomic operations (hint: no 64-bit atomic operations are
>> implemented on i386's). If they need to be atomic, then they must use
>> locks.
>
>Jus
* Bruce Evans <[EMAIL PROTECTED]> [010116 19:03] wrote:
> On Tue, 16 Jan 2001, Julian Elischer wrote:
>
> > Bruce Evans wrote:
> > > I bother with 64-bit longs whether I need to or not :-). They get used on
> > > i386's mainly in old code and interfaces that don't use typedefs.
> > > Hopefully 6
On Tue, 16 Jan 2001, Julian Elischer wrote:
> Bruce Evans wrote:
> > I bother with 64-bit longs whether I need to or not :-). They get used on
> > i386's mainly in old code and interfaces that don't use typedefs.
> > Hopefully 64-bit scalars will never need to be accessed atomically.
>
> Too la
Bruce Evans wrote:
>
> On Mon, 15 Jan 2001, John Baldwin wrote:
>
> > On 14-Jan-01 Peter Jeremy wrote:
> > > And for BDE's benefit - atomic.h is broken for IA32's with 64-bit
> > > longs. (I believe that can be fixed for Pentiums and above using
> > > CMPXCHG8B, but I can't test the code).
> >
On Mon, 15 Jan 2001, John Baldwin wrote:
> On 14-Jan-01 Peter Jeremy wrote:
> > And for BDE's benefit - atomic.h is broken for IA32's with 64-bit
> > longs. (I believe that can be fixed for Pentiums and above using
> > CMPXCHG8B, but I can't test the code).
>
> The i386 with 64-bit longs doesn'
On 14-Jan-01 Peter Jeremy wrote:
> On 2001-Jan-14 23:02:28 +0200, Mark Murray <[EMAIL PROTECTED]> wrote:
>>Hi John
>>
>>There seems to be same breakage in the atomic stuff:
>>
>>link_elf: symbol atomic_load_acq_int undefined
>>KLD file random.ko - could not finalize loading
>>
>>I back out the la
On 2001-Jan-14 17:05:20 -0800, David O'Brien <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote:
>> Due to incompatibilities between __asm in different versions of gcc,
>> several different versions of various macros (and expansions) are
>> necessary.
>
>Why i
On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote:
> Due to incompatibilities between __asm in different versions of gcc,
> several different versions of various macros (and expansions) are
> necessary.
Why is that?? The base, and *only* supported compiler for building
kernels is GCC
On 2001-Jan-14 23:02:28 +0200, Mark Murray <[EMAIL PROTECTED]> wrote:
>Hi John
>
>There seems to be same breakage in the atomic stuff:
>
>link_elf: symbol atomic_load_acq_int undefined
>KLD file random.ko - could not finalize loading
>
>I back out the latest commit to sys/i386/include/atomic.h, an
Hi John
There seems to be same breakage in the atomic stuff:
link_elf: symbol atomic_load_acq_int undefined
KLD file random.ko - could not finalize loading
I back out the latest commit to sys/i386/include/atomic.h, and things
work a bit better (on my laptop).
M
--
Mark Murray
Warning: this .s
21 matches
Mail list logo
