On Nov 20, 2010, at 12:25 AM, Johnny Billquist wrote:
> Matt,
>
> On 2010-11-13 04:17, Matt Thomas wrote:
>> The VAX now has a fast non-MP emulation of atomic_cas so that should be
>> less of an issue.
>
> I looked at this code, as well as your musings about the design. Did you miss
> one step
Matt,
On 2010-11-13 04:17, Matt Thomas wrote:
The VAX now has a fast non-MP emulation of atomic_cas so that should be
less of an issue.
I looked at this code, as well as your musings about the design. Did you
miss one step in there, or did I miss something?
I thought that we needed to reset
On Mon, Nov 15, 2010 at 05:40:05PM +0100, Johnny Billquist wrote:
> [...] but rwlocks can not be fixed without more work. :-(
I wouldn't be particularly surprised if replacing the current overbred
rwlock code with a simple implementation using a single mutex and
condvar made it go faster... or at
On 11/13/10 11:16, Anders Magnusson wrote:
(a little side-note, but may be interesting)
On 11/13/2010 04:17 AM, Matt Thomas wrote:
Eventually, most operations come down to compare and swap. It's just too
damn useful to not have as a primitive. Even if some of the platforms
have to emulate it so
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> No it doesen't because all those macros assume the value is being
> transferred from one register to another rather than regiser to memory.
> The assignment:
>
> foo.size = htole64(size);
>
> Cannot be replaced with:
>
(a little side-note, but may be interesting)
On 11/13/2010 04:17 AM, Matt Thomas wrote:
Eventually, most operations come down to compare and swap. It's just too
damn useful to not have as a primitive. Even if some of the platforms
have to emulate it somehow. Just because an architecture is 30
On Nov 12, 2010, at 8:02 PM, Johnny Billquist wrote:
> On 2010-11-13 04:49, Matt Thomas wrote:
>>
>> simple locks are not mutexes. mutexes are more complex and
>> test-and-set isn't adequate to do the job.
>
> I (obviously) totally disagree... :-)
> A mutex is simply just an object that only o
On 2010-11-13 04:49, Matt Thomas wrote:
On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:
Eh...?
Now I'm not following you.
Yes, if you grab a lock in some code, and then get an interrupt, and in that
interrupt routine, you try to grab the same lock, you loose.
That should be pretty obviou
On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:
>
> Eh...?
> Now I'm not following you.
> Yes, if you grab a lock in some code, and then get an interrupt, and in that
> interrupt routine, you try to grab the same lock, you loose.
> That should be pretty obvious.
> How does using CAS to impl
On 2010-11-13 04:17, Matt Thomas wrote:
On Nov 12, 2010, at 6:49 PM, Johnny Billquist wrote:
On 2010-11-13 03:26, Thor Lancelot Simon wrote:
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
It's pretty clear, looking at the VAX architecture and many of the early
VAX models
On Nov 12, 2010, at 6:49 PM, Johnny Billquist wrote:
> On 2010-11-13 03:26, Thor Lancelot Simon wrote:
>> On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
>>>
>>> I just wanted a mutex and a lock interface which I could inline, and
>>> which only had the idea that I wanted to ta
On 2010-11-13 03:26, Thor Lancelot Simon wrote:
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
I just wanted a mutex and a lock interface which I could inline, and
which only had the idea that I wanted to take or release a mutex or a
lock. Some additional functions, like upgr
On Fri, Nov 12, 2010 at 06:35:32PM +, Eduardo Horvath wrote:
> On Fri, 12 Nov 2010, Thor Lancelot Simon wrote:
>
> While support for other platforms are not being dropped, there does seem
> to be an implicit assumption that everyone is running on x86 (or more
> specifically amd64) and code s
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
>
> I just wanted a mutex and a lock interface which I could inline, and
> which only had the idea that I wanted to take or release a mutex or a
> lock. Some additional functions, like upgrading and downgrading rwlocks
> is als
On Nov 12, 2010, at 5:32 PM, Thor Lancelot Simon wrote:
> On Fri, Nov 12, 2010 at 01:58:59PM -0500, Paul Koning wrote:
>>
>> VAX support (and for that matter, pdp11 support) is still part of
>> gcc-current.
>
> Yes, because a NetBSD developer brought it back to life!
Ok, I get it now. Note t
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
> #define htole64(x) \
[blah]
>
> // just to exercise it a bit
> struct s {
> uint64_t foo[12];
> };
>
> uint64_t
> foo(struct s *s)
> {
> return s->foo[10] + htole64(s->foo[11]);
> }
>
On 2010-11-12 19:07, Thor Lancelot Simon wrote:
On Fri, Nov 12, 2010 at 07:05:34PM +0200, Antti Kantee wrote:
On Fri Nov 12 2010 at 15:25:04 +0100, Johnny Billquist wrote:
Freeway design is not driven by the requirements of the horse. If a horse
occasionally wants to gallop down a freeway, we'
On Nov 12, 2010, at 4:23 PM, Eduardo Horvath wrote:
> On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
>
>> On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
>>
>>> On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size = htole64(
On Fri, Nov 12, 2010 at 21:29:58 +, Eduardo Horvath wrote:
> > On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
> > > On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
> > >
> > > > On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
> > > >
> > > > > On Fri, Nov 1
On Fri, Nov 12, 2010 at 01:58:59PM -0500, Paul Koning wrote:
>
> VAX support (and for that matter, pdp11 support) is still part of gcc-current.
Yes, because a NetBSD developer brought it back to life!
--
Thor Lancelot Simont...@rek.tjls.com
"We canno
On Fri, Nov 12, 2010 at 09:29:58PM +, Eduardo Horvath wrote:
> > Doesn't really matter, as the compiler can reorder that and with the
> > right constraints, it certainly should.
>
> So instead of a single store you force a register spill, a load, and
> another store? That's even worse than 8
On Fri, 12 Nov 2010, Joerg Sonnenberger wrote:
> On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
> > On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
> >
> > > On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
> > >
> > > > On Fri, Nov 12, 2010 at 08:31:39PM +,
On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
> On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
>
> > On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
> >
> > > On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> > > > The assignment:
> > > >
> >
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
> On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
>
> > On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> > > The assignment:
> > >
> > > foo.size = htole64(size);
> > >
> > > Cannot be replaced with:
> > >
> > >
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
> On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> > The assignment:
> >
> > foo.size = htole64(size);
> >
> > Cannot be replaced with:
> >
> > __inline __asm("stxa %1, [%0] ASI_LITLE" : &foo.size : size);
>
>
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> The assignment:
>
> foo.size = htole64(size);
>
> Cannot be replaced with:
>
> __inline __asm("stxa %1, [%0] ASI_LITLE" : &foo.size : size);
Actually, it should be possible to do exactly that if you allow the
output register to
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> > If you look at sys/endian.h, that is exactly the kind of abstraction the
> > API makes easy to use. Just provide the proper inline functions for your
> > platform.
>
> No it doesen't because all those macros assume the value is b
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> > If you look at sys/endian.h, that is exactly the kind of abstraction the
> > API makes easy to use. Just provide the proper inline functions for your
> > platform.
>
> No it doesen't because all those macros assume the value is b
On Fri, 12 Nov 2010, Joerg Sonnenberger wrote:
> On Fri, Nov 12, 2010 at 06:35:32PM +, Eduardo Horvath wrote:
> > Take, for example, the simple act of byte swapping network data. x86 has
> > a bswap instruction. SPARC and PowerPC architectures have a multiplexer
> > on the load/store. (Do
On Fri, Nov 12, 2010 at 06:35:32PM +, Eduardo Horvath wrote:
> Take, for example, the simple act of byte swapping network data. x86 has
> a bswap instruction. SPARC and PowerPC architectures have a multiplexer
> on the load/store. (Don't know about MIPS, don't remember about ARM.) In
> o
On Nov 12, 2010, at 1:07 PM, Thor Lancelot Simon wrote:
> ...
> What Antti said. And, further, I would like to point out that you (Johnny)
> didn't step forward and resuscitate VAX support in GCC -- one of the same
> NetBSD developers you're lambasting for not caring enough about whether
> old a
On Fri, 12 Nov 2010, Thor Lancelot Simon wrote:
> The claim that NetBSD only cares about x86 is even more absurd. NetBSD
> supports a huge array of architectures, usually in both their modern and
> ancient implementations. We'll run on everything from R2000 to the newest
> multicore 64-bit MIPS
On Fri, Nov 12, 2010 at 07:05:34PM +0200, Antti Kantee wrote:
> On Fri Nov 12 2010 at 15:25:04 +0100, Johnny Billquist wrote:
> > >Freeway design is not driven by the requirements of the horse. If a horse
> > >occasionally wants to gallop down a freeway, we're happy to let it as long
> > >as it do
33 matches
Mail list logo
