On 2014-07-17 16:53, Greg Stark wrote:
> On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon <tls@panix.com> wrote:
>> Except, of course, for IEEE floating point, because the VAX's floating point
>> unit simply does not provide that
>
> Actually I think that's relevant. We usually get focused on the
> concurrency because that's an area where architectures vary a lot but
> it sounds like VAX barely supports multiple CPUs and generally older
> architectures had fairly mundane concurrency semantics since they were
> designed to work with existing toolchains. From memory it wasn't until
> later Sparc chips and Alpha that people started to experiment with
> looser concurrency models and expecting the toolchains to satisfy
> complex constraints to make them work.
Well, VAXen support multiple CPUs just fine. However, NetBSD/vax barely
have support for it. That could of course change with time, as there are
plenty of multiple CPU machines around. We just need to add support for
them in NetBSD...
Also, VAX did not use CAS as the general paradigm for atomic writes and
so on, but have other explicit instructions that are guaranteed to be
atomic. NetBSD/vax don't use the VAX specific instructions, but emulates
CAS in the kernel instead. But I don't remember how that extends to
userland. It's obviously easiest if userland programs use the pthread
library functions, which are guaranteed to work right even in
multiprocessor environment.
Implementing your own spinlocks is of course possible, but a horrible
way to use machine resources in userland.
Johnny
--
Johnny Billquist || "I'm on a bus || on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol