Brent Fulgham | 1 Apr 01:48 2005
Picon

win32 Status

I was curious how the win32 work was coming.  I
haven't found any reference to the work since the
early July postings by Alistair...

Thanks,

-Brent

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Florian M. Weps | 1 Apr 12:07 2005
Picon

pthreads on alpha

Hi

I'm poking around in the list archives, on blogs and in CVS to see what
has to be done to port the x86-64 pthreads stuff to alpha-linux, so I can
play seriously with apache and modlisp:

sort out TLS in the run-time and compiler x86-64 seems to use the %fs
register just like the x86 port. I saw some notes somewhere about how
linux kernel 2.6's improved access to LDT could be used instead. OTOH
the alpha has lots of GPRs, and that approach might work on BSD and
Tru64 as well.

mutex/futex seems to be fairly generic (i.e. not tied to x86-64)

gc seems to be fairly generic.

If I overlooked anything glaringly obvious, I'd be grateful for
pointers and nudges of course.

I'll keep the list posted on any progress I make. Might not happen,
of course.

Cheers,
Florian

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
(Continue reading)

Dario Lah | 1 Apr 13:06 2005
Picon

OS X/PPC threads

Hi,
can anyone comment possibility of threading support on Mac OS X?

Dario

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Daniel Barlow | 1 Apr 12:49 2005
Picon

Re: pthreads on alpha

"Florian M. Weps" <fmw <at> hactrn.ch> writes:

> I'm poking around in the list archives, on blogs and in CVS to see what
> has to be done to port the x86-64 pthreads stuff to alpha-linux, so I can
> play seriously with apache and modlisp:
>
> sort out TLS in the run-time and compiler x86-64 seems to use the %fs
> register just like the x86 port. I saw some notes somewhere about how
> linux kernel 2.6's improved access to LDT could be used instead. OTOH
> the alpha has lots of GPRs, and that approach might work on BSD and
> Tru64 as well.

I'm not sure where you saw that about %fs, but it's not true.  The
x86-64 port uses r12 for thread-local access in Lisp, and a pthread
thread-local variable (which I think is called "specials", but I don't
have the code in front of me) in C.  If you look at call_into_lisp you
can see the assembler that loads one from the other.

This should be pretty straightforward to alpha-ise.  As you say, it
has a reasonable number of GPRs.

(Note that the new stuff for LDT entries in 2.6 is a side issue: you
can allocate descriptor table entries however you wish, but you'd
still need a segment selector - %fs or %gs - to point at them)

> mutex/futex seems to be fairly generic (i.e. not tied to x86-64)

You'll need to implement spinlocks in some useful-for-alpha way.  On
x86{,-64} we use LOCK CMPXCHG, but I think the Alpha will want some
construct based on load-locked/store-conditional instead.
(Continue reading)

Nikodemus Siivola | 1 Apr 15:31 2005
Picon

Irrational issues

The following test reveals problems on x86 with several irrational 
functions due to various %FOO functions not being defined (and doing the
corresponding defuns fixes this).

However, this behaviour is not exhibited if the DF unconditionally returns 
least-posive-double-float. So, before adding the defuns for x86 I was 
wondering if the compiler could be made to deal with this instead with 
"reasonable" effort?

(declaim (inline df))
(defun df (x)
   (ecase x (1 least-positive-double-float)))

(macrolet ((test (fun)
              (let ((name (intern (format nil "TEST-CONSTANT-~A" fun))))
                `(progn
                   (defun ,name () (,fun (df 1)))
                   (multiple-value-bind (res err) (ignore-errors (,name))
                     (when (and (not res) err)
                       (print (list :failed ',fun err))))))))
   (test sqrt)
   (test log)
   (test atan)
   (test exp))

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

(Continue reading)

Brian Mastenbrook | 1 Apr 15:51 2005
Picon

Re: OS X/PPC threads


On Apr 1, 2005, at 5:06 AM, Dario Lah wrote:

> Hi,
> can anyone comment possibility of threading support on Mac OS X?
>
> Dario

It's waiting on someone to take on porting the generational garbage 
collector to PowerPC. After that, threads will need one or two VOPs and 
native locking support written, but then might just work (ILTWIS"J").
--
Brian Mastenbrook
brian <at> mastenbrook.net
http://www.iscblog.info/

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Denis Bueno | 1 Apr 16:33 2005
Picon

Re: OS X/PPC threads

On Apr 1, 2005 6:06 AM, Dario Lah <dlah <at> linux.hr> wrote:
> Hi,
> can anyone comment possibility of threading support on Mac OS X?

I can't comment on it's availability, but, I'd like to work on that.
According to an earlier post on this newsgroup
(http://www.caddr.com/macho/archives/sbcl-devel/2005-2/4579.html) Dan
Barlow said that since he's using pthreads on amd64, it might be
easier to use pthreads on some architecture like ppc/darwin. Hopefully
this means threads on os x will be available "soon".

--

-- 
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Florian M. Weps | 1 Apr 21:14 2005
Picon

Re: pthreads on alpha

On Fri, Apr 01, 2005 at 02:30:49PM +0200, Florian M. Weps wrote:
> On Fri, Apr 01, 2005 at 11:49:54AM +0100, Daniel Barlow wrote:
> > I'm not sure where you saw that about %fs, but it's not true.  The
> > x86-64 port uses r12 for thread-local access in Lisp, and a pthread
> > thread-local variable (which I think is called "specials", but I don't
> > have the code in front of me) in C.  If you look at call_into_lisp you
> > can see the assembler that loads one from the other.
> 
> I was grepping around casually, and found some references to %fs in
> 
>   runtime/x86-64-linux-os.c   1.1.4.2
> 
> So I jumped to the wrong conclusion.

I was on the wrong branch as well - amd64-pthread-branch is 1.2.6 not 1.1.4

Cheers,
Florian

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Friedrich Dominicus | 1 Apr 12:08 2005
Picon

Some unrelated questions

Well I'm more and more on the "Lisp"-trip and appriciate especiall the
integration of SBCL and Emacs. I wonder how or if the interface to
SWANK can be used to build some kind of "hand tailored"
applications. Does anyone know of such a thing?

Next question (unrelated). I asked some days ago about another ending
for the compiled files. Someone pointed out to me that I just have to
change one of the variables. I tried that an recompiled SBCL but the
ending is still the same. Does anyone know where on had to put his
hands for changing that?

A related question: Would it be better to instruct the make facility
to the binary files in a special subdirectory and keep the endings as
is?

Regards
Friedrich

-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Florian M. Weps | 1 Apr 14:30 2005
Picon

Re: pthreads on alpha

On Fri, Apr 01, 2005 at 11:49:54AM +0100, Daniel Barlow wrote:
> I'm not sure where you saw that about %fs, but it's not true.  The
> x86-64 port uses r12 for thread-local access in Lisp, and a pthread
> thread-local variable (which I think is called "specials", but I don't
> have the code in front of me) in C.  If you look at call_into_lisp you
> can see the assembler that loads one from the other.

I was grepping around casually, and found some references to %fs in

  runtime/x86-64-linux-os.c   1.1.4.2

So I jumped to the wrong conclusion.

> You'll need to implement spinlocks in some useful-for-alpha way.  On
> x86{,-64} we use LOCK CMPXCHG, but I think the Alpha will want some
> construct based on load-locked/store-conditional instead.

Thanks, I'll go peek at the linux kernel sources.

> GC is actually going to be your biggest task, I think, as the Alpha
> uses cheneygc and the threads stuff currently only deals with gencgc.
> The important difference is actually the allocator rtaher than the
> properties of the GC itself: with gencgc we can have separate
> allocation regions per thread so that most allocation is
> parallelisable (until the region fills), but cheneygc has only a
> single "next free word" pointer.

Well, that's something to read for the week-end.

Cheers,
(Continue reading)


Gmane