From: David Steuber
Subject: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <873cecfr4s.fsf@verizon.net>
Early Wednesday morning, I fetched a virgin copy of GNU Emacs from the
·······@subversions.gnu.org CVS repository and did a successful build
on my PowerBook G4 12" running 10.2.6 and Fink. It looks good! I
even set prefix=/usr in ./configure. I have removed the Fink build of
Emacs. I now have just one Emacs running. I've got Emacs.app in the
dock. This is great!
This has me thinking that I can start moving mail and news functions
from my Debian box over to my PowerBook. A dual Athalon is a loud
box, and I just can't stand the racket of all those fans. I could
also do without the electric tax from the 400W power supply. It is
better to save the Debian box for the CPU hungry stuff.
I don't know how long migration will take. Fink has some issues with
self-update. It looks like I have to fiddle with it a bit as it
expects to hit my local CVS repository (bad, bad, bad). I would like
to use Exim as my MTA. Then I can just pull over my .fetchmailrc
file. My MTA has to know to forward out going mail to my ISP.
The other thing is that on my Debian system, I am setup for CMUCL. I
could just get OpenMCL and install ilisp. Or, I can see how much work
it would take to port CMUCL over to the PPC line. With the new
PPC970s now coming out, I wish I could afford a G5. That looks like
the future.
I also need to bang on the Mac OS X port before I switch over.
Again, Kudos.
P.S. For those who don't know what I'm talking about, see:
http://members.shaw.ca/akochoi-emacs/index.html
A screen shot of the Emacs splash screen (reduced by 75% courtesy of
ImageMagick):
http://www.david-steuber.com/pix/EmacsOSX.jpeg
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
>>>>> "David" == David Steuber <·············@verizon.net> writes:
David> The other thing is that on my Debian system, I am setup for CMUCL. I
David> could just get OpenMCL and install ilisp. Or, I can see how much work
David> it would take to port CMUCL over to the PPC line. With the new
SBCL runs on Mac OS X. You can try that. There is interest in
porting CMUCL to Mac OS X as well and someone was working on that, but
I don't know the current status.
Ray
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <877k3nia0s.fsf@verizon.net>
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "David" == David Steuber <·············@verizon.net> writes:
>
> David> The other thing is that on my Debian system, I am setup for CMUCL. I
> David> could just get OpenMCL and install ilisp. Or, I can see how much work
> David> it would take to port CMUCL over to the PPC line. With the new
>
> SBCL runs on Mac OS X. You can try that. There is interest in
> porting CMUCL to Mac OS X as well and someone was working on that, but
> I don't know the current status.
I'll check around. I doubt that I am qualified to help with the
porting effort of CMUCL if it exists. But it is nice to think about.
I suppose the ease of the project would have a lot to do with how the
machine code is finally generated. I've not looked at it in detail,
but apparently GCC has some tricks for that like using some sort of
intermediary pseudo-machine code or something.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
David Steuber <·············@verizon.net> writes:
> Raymond Toy <···@rtp.ericsson.se> writes:
>
>> SBCL runs on Mac OS X. You can try that. There is interest in
>> porting CMUCL to Mac OS X as well and someone was working on that, but
>> I don't know the current status.
>
> I'll check around. I doubt that I am qualified to help with the
> porting effort of CMUCL if it exists. But it is nice to think about.
> I suppose the ease of the project would have a lot to do with how the
> machine code is finally generated.
Not really, because the port of SBCL has done all the hard work.
"All" you would need to do is backport the SBCL backend to CMUCL.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <874qyqp08q.fsf@verizon.net>
Christophe Rhodes <·····@cam.ac.uk> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Raymond Toy <···@rtp.ericsson.se> writes:
> >
> >> SBCL runs on Mac OS X. You can try that. There is interest in
> >> porting CMUCL to Mac OS X as well and someone was working on that, but
> >> I don't know the current status.
> >
> > I'll check around. I doubt that I am qualified to help with the
> > porting effort of CMUCL if it exists. But it is nice to think about.
> > I suppose the ease of the project would have a lot to do with how the
> > machine code is finally generated.
>
> Not really, because the port of SBCL has done all the hard work.
> "All" you would need to do is backport the SBCL backend to CMUCL.
Depending on the severity of those quotes you used, that sounds very
promising.
I don't want to sound like I am married to CMUCL. I just don't want
to jump around on too many Lisp systems to keep in my tiny brain. I
also like the CMUCL licensing. An ideal situation for me would be a
cross-platform Common Lisp environment which looks the same on Linux
as it does on OS X.
The cross-platform capabilities of GNU Emacs are why I took the
trouble to compile the CVS sources on my PowerBook. That actually
turned out to be the path of least resistance for me to have a good
Emacs on OS X. That is why I am grateful to Mr. Choi and the others,
whoever they may be, for their work.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
From: Peter Seibel
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <m3ad8i2iil.fsf@javamonkey.com>
David Steuber <·············@verizon.net> writes:
> I don't want to sound like I am married to CMUCL. I just don't want
> to jump around on too many Lisp systems to keep in my tiny brain. I
> also like the CMUCL licensing. An ideal situation for me would be a
> cross-platform Common Lisp environment which looks the same on Linux
> as it does on OS X.
I think you really want SBCL. It's based on CMU CL and thus has the
same licensing and much the same feature set. (The differences are
unlike to matter to you at this point in your Lisp career, if ever.)
And it's already been ported to OS X.
> The cross-platform capabilities of GNU Emacs are why I took the
> trouble to compile the CVS sources on my PowerBook. That actually
> turned out to be the path of least resistance for me to have a good
> Emacs on OS X. That is why I am grateful to Mr. Choi and the others,
> whoever they may be, for their work.
I haven't really bothered setting up a for-real Lisp environment on my
iBook since I do most of my work on a GNU/Linux desktop. But I did
build SBCL just to see if I could--no problems at all. You do need an
existing Lisp to build it--I just grabbed the Darwin binary to
bootstrap myself.
I suspect that if you're using GNU Emacs, SBCL, and ILISP you're going
to have a pretty portable experience. And someday, someone will
probably take the bait and port SBCL to Windows and you'll have the
big three covered.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <87y8w0628f.fsf@verizon.net>
Peter Seibel <·····@javamonkey.com> writes:
> I think you really want SBCL. It's based on CMU CL and thus has the
> same licensing and much the same feature set.
...
> And it's already been ported to OS X.
Sounds like a plan.
> I haven't really bothered setting up a for-real Lisp environment on my
> iBook since I do most of my work on a GNU/Linux desktop. But I did
> build SBCL just to see if I could--no problems at all. You do need an
> existing Lisp to build it--I just grabbed the Darwin binary to
> bootstrap myself.
I'm still using 'ssh -X' to talk to my Debian box from my PowerBook.
However, that thing is like a 747 idling in my apartment and I could
do without the racket except for when I have real stuff going on. I
do like the system. It's just soooo loud.
Once I've got my e-mail and Usenet moved over to the PowerBook, I'm
shutting off the engines.
> I suspect that if you're using GNU Emacs, SBCL, and ILISP you're going
> to have a pretty portable experience. And someday, someone will
> probably take the bait and port SBCL to Windows and you'll have the
> big three covered.
GNU Emacs with ILISP is the plan. SBCL sounds like the way to go. If
someone does port SBCL (or a Lisp that will compile all the code I
write without complaint) over to Windows, then I will be quite happy.
I also don't plan to leave any of the BSDs in the cold. But I can
only play with so many shiny things before I act like a ferret with a
terminal sugar overdose. L< http://www.sluggy.com/ >
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
David Steuber wrote:
> This has me thinking that I can start moving mail and news functions
> from my Debian box over to my PowerBook. A dual Athalon is a loud
> box, and I just can't stand the racket of all those fans. I could
> also do without the electric tax from the 400W power supply. It is
> better to save the Debian box for the CPU hungry stuff.
My single Athlon was noisy enough. But I have succeeded in quieting
it to almost nothing. See
http://www.endpcnoise.com/
Most of the noise was from the CPU cooler and my hard drive.
I replaced them with a Nexus KCZ-2700 and a Seagate Hard Drive.
Finally some peace! Saving my pennies to replace the power supply and case
as they are the last sources of noise.
Wade
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <87d6dfia5k.fsf@verizon.net>
Wade Humeniuk <········@nospamtelus.net> writes:
> My single Athlon was noisy enough. But I have succeeded in quieting
> it to almost nothing. See
>
> http://www.endpcnoise.com/
>
> Most of the noise was from the CPU cooler and my hard drive.
> I replaced them with a Nexus KCZ-2700 and a Seagate Hard Drive.
> Finally some peace! Saving my pennies to replace the power supply and case
> as they are the last sources of noise.
I've got two bearing fans on the CPUs that seem to run at slightly
different speeds. The drive is quiet enough as are the case fans.
The PS fan is the other noisy deal. I actually got in there with a
SPL meter to see where all the racket was coming from.
I love having a small super computer. I just wish it didn't make big
super computer noise. Thanks for that link.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
On Wed, 01 Oct 2003 23:57:30 GMT, David Steuber
<·············@verizon.net> wrote:
>Early Wednesday morning, I fetched a virgin copy of GNU Emacs from the
>·······@subversions.gnu.org CVS repository and did a successful build
>on my PowerBook G4 12" running 10.2.6 and Fink. It looks good! I
>even set prefix=/usr in ./configure. I have removed the Fink build of
>Emacs. I now have just one Emacs running. I've got Emacs.app in the
>dock. This is great!
I'll have to give this a try tonight. I have a pretty good build of
Emacs running right now, but it might be Carbonized. Is this version
using Aqua?
>
>This has me thinking that I can start moving mail and news functions
>from my Debian box over to my PowerBook. A dual Athalon is a loud
>box, and I just can't stand the racket of all those fans. I could
>also do without the electric tax from the 400W power supply. It is
>better to save the Debian box for the CPU hungry stuff.
I second that, I use my powerbook for almost everything now.
>
>I don't know how long migration will take. Fink has some issues with
>self-update. It looks like I have to fiddle with it a bit as it
>expects to hit my local CVS repository (bad, bad, bad). I would like
>to use Exim as my MTA. Then I can just pull over my .fetchmailrc
>file. My MTA has to know to forward out going mail to my ISP.
>
Yeah I have those same problems with Fink. I did get it to self
update by using dpkg with it IIRC.
>The other thing is that on my Debian system, I am setup for CMUCL. I
>could just get OpenMCL and install ilisp. Or, I can see how much work
>it would take to port CMUCL over to the PPC line. With the new
>PPC970s now coming out, I wish I could afford a G5. That looks like
>the future.
You could also give SBCL a try. It runs on OS X. I have been setting
it up, but I am running into a bit of trouble with ILISP. It's
spitting out an error message when I launch. Interestingly if I just
exit the debug, I can continue with any problems. It's pretty nice so
far though.
>
>I also need to bang on the Mac OS X port before I switch over.
>
>Again, Kudos.
>
>P.S. For those who don't know what I'm talking about, see:
>
> http://members.shaw.ca/akochoi-emacs/index.html
>
>A screen shot of the Emacs splash screen (reduced by 75% courtesy of
>ImageMagick):
>
> http://www.david-steuber.com/pix/EmacsOSX.jpeg
Uh..nice background. :)
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <87isn7ib39.fsf@verizon.net>
Doug Tolton <····@nospam.com> writes:
> On Wed, 01 Oct 2003 23:57:30 GMT, David Steuber
> <·············@verizon.net> wrote:
>
> >Early Wednesday morning, I fetched a virgin copy of GNU Emacs from the
> >·······@subversions.gnu.org CVS repository and did a successful build
> >on my PowerBook G4 12" running 10.2.6 and Fink. It looks good! I
> >even set prefix=/usr in ./configure. I have removed the Fink build of
> >Emacs. I now have just one Emacs running. I've got Emacs.app in the
> >dock. This is great!
>
> I'll have to give this a try tonight. I have a pretty good build of
> Emacs running right now, but it might be Carbonized. Is this version
> using Aqua?
No, this is Carbon. It also uses the standard Emacs keys, although I
think there is some CUA stuff in there for Apple. The site I provided
a URL for has lots of info. There is a link over there to an Aqua
version in development, IIRC.
> Yeah I have those same problems with Fink. I did get it to self
> update by using dpkg with it IIRC.
I updated packaged eventually using dselect. Unfortunately, dselect
can be quite nasty in the Terminal program. I'm going to have to try
it in xterm.
> You could also give SBCL a try. It runs on OS X. I have been setting
> it up, but I am running into a bit of trouble with ILISP. It's
> spitting out an error message when I launch. Interestingly if I just
> exit the debug, I can continue with any problems. It's pretty nice so
> far though.
I haven't tried setting up ilisp yet. I have clisp, so I should at
least be able to hook into that. I need to grab the latest OpenMCL if
I don't have it already. One thing I've always liked about Debian is
the package management sets things up properly. Things like ilisp.
I've not actually had to do any configuration myself.
> >P.S. For those who don't know what I'm talking about, see:
> >
> > http://members.shaw.ca/akochoi-emacs/index.html
> >
> >A screen shot of the Emacs splash screen (reduced by 75% courtesy of
> >ImageMagick):
> >
> > http://www.david-steuber.com/pix/EmacsOSX.jpeg
>
> Uh..nice background. :)
Yeah, I like Kylie.
I've been banging on Emacs for OS X a bit. The command key is Meta.
ESC works to in the usual fashion. Unlike other versions of Emacs I've
had on my PowerBook, C-h actually calls up help instead of doing a
backspace and delete.
I have a Microsoft Optical track ball mouse thing hooked up (USB) which
has a scroll wheel middle button. It works properly with the Emacs.
So far, I am quite pleased. I am wondering if I have to run 'make
bootstrap' with each CVS update I do. That takes a long time to run
on my 866Mhz G4. Hey, it's a laptop.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> Doug Tolton <····@nospam.com> writes:
>
> > On Wed, 01 Oct 2003 23:57:30 GMT, David Steuber
> > <·············@verizon.net> wrote:
> >
> > >Early Wednesday morning, I fetched a virgin copy of GNU Emacs from the
> > >·······@subversions.gnu.org CVS repository and did a successful build
> > >on my PowerBook G4 12" running 10.2.6 and Fink. It looks good! I
> > >even set prefix=/usr in ./configure. I have removed the Fink build of
> > >Emacs. I now have just one Emacs running. I've got Emacs.app in the
> > >dock. This is great!
> >
> > I'll have to give this a try tonight. I have a pretty good build of
> > Emacs running right now, but it might be Carbonized. Is this version
> > using Aqua?
>
> No, this is Carbon. It also uses the standard Emacs keys, although I
> think there is some CUA stuff in there for Apple. The site I provided
> a URL for has lots of info. There is a link over there to an Aqua
> version in development, IIRC.
>
> > Yeah I have those same problems with Fink. I did get it to self
> > update by using dpkg with it IIRC.
>
> I updated packaged eventually using dselect. Unfortunately, dselect
> can be quite nasty in the Terminal program. I'm going to have to try
> it in xterm.
>
> > You could also give SBCL a try. It runs on OS X. I have been setting
> > it up, but I am running into a bit of trouble with ILISP. It's
> > spitting out an error message when I launch. Interestingly if I just
> > exit the debug, I can continue with any problems. It's pretty nice so
> > far though.
>
> I haven't tried setting up ilisp yet. I have clisp, so I should at
> least be able to hook into that. I need to grab the latest OpenMCL if
> I don't have it already. One thing I've always liked about Debian is
> the package management sets things up properly. Things like ilisp.
> I've not actually had to do any configuration myself.
I use openmcl and ilisp habitually, using the same emacs you're using
(but on a PowerBook with a much larger screen :-)).
It's possible to build apps with openmcl that use the Cocoa UI
framework--not easy yet, but possible. There are efforts underway to
make it easier, and the latest sources from cvs on the 0.14 branch have
some of that work in them (as well as native thread support). Also, the
lastest McCLIM sources build against the latest openmcl cvs sources
(0.14 branch) and the examples work under Apple's X11. There are
efforts to port Portable Hemlock and to build a native Aqua backend for
McCLIM.
Any of the abovementioned efforts would be useful places to spend
hacking efforts. I don't know if the McCLIM listener works on openmcl,
but it would also be kind of cool to get that working.
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <87ad8ip0qa.fsf@verizon.net>
mikel <·····@evins.net> writes:
> I use openmcl and ilisp habitually, using the same emacs you're using
> (but on a PowerBook with a much larger screen :-)).
Do you need a pointer to a self help group? ;-)
I never expected to use a 12" laptop as a substitute for a desktop
system. If I did, and I had the cash, I would have the 17" stuffed
with all the bells and whistles. I'm now wondering when Apple will
offer the G5 in its PowerBook lineup and when they will have the nerve
to do what no one has done before: offer a dual CPU notebook
computer.
> It's possible to build apps with openmcl that use the Cocoa UI
> framework--not easy yet, but possible. There are efforts underway to
> make it easier, and the latest sources from cvs on the 0.14 branch have
> some of that work in them (as well as native thread support). Also, the
> lastest McCLIM sources build against the latest openmcl cvs sources
> (0.14 branch) and the examples work under Apple's X11. There are
> efforts to port Portable Hemlock and to build a native Aqua backend for
> McCLIM.
I think I still have some confusion regarding all the terminology used
in Mac development circles. Perhaps you can confirm that I've got the
terms right:
* Quartz: The OS X GUI.
* Aqua: The newest API for Quartz.
* Carbon: A "Classic" API for porting to Quartz quickly.
* Classic: That old pre OS X non-Unix dreck
I have no idea how much stuff Panther will end up breaking. Hopefully
the answer is none of the above. I personally don't much care if
apple supports the old applications or not, but some people seem to
think that I shouldn't be a solipsist. Since they only exist in my
imagination, I'm not sure I should worry about what they think ;-)
> Any of the abovementioned efforts would be useful places to spend
> hacking efforts. I don't know if the McCLIM listener works on openmcl,
> but it would also be kind of cool to get that working.
I would actually be interested in having Aqua work. Rather, I would
like to develop applications that are portable between Unix and Mac OS
X with the appropriate native look and feel. I would also like this
to work better than what Sun did with AWT/Swing for Java.
Proper and portable threading support in CL would also be nice because
dual CPU systems are likely to only get more popular over time and it
would be nice to take advantage of multiple CPUs. Even so, the use of
threading also simplifies application design when the appropriate
abstraction is available. I think Java's threading model is actually
well done unlike AWT/Swing. I prefer the Win32 API for threading, but
I don't program to that anymore for now. I have not yet experienced
the joy of pthreads. I have heard that the current pthread libs for
Linux (or perhaps all GNU libc based systems) are rather ungood. I
certainly don't care for threads looking like additional processes
with the ps command.
Because I am easily distracted by shiny things, I am still a neophyte
Lisp programmer. I have bought into the hype that Lisp is The True
Language for computer programming though.
My background is with C++ for compiled languages and Perl for
scripting, so I probably have certain biases.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
David Steuber <·············@verizon.net> writes:
> I never expected to use a 12" laptop as a substitute for a desktop
> system. If I did, and I had the cash, I would have the 17" stuffed
> with all the bells and whistles.
Nor did I -- but I seem to be using it more and more like one. It's
so quiet, and the fullsized keyboard makes it possible. I could use a
linux box (whirrrr), the Sun (WHIRRRRR), or the iBook (...). Hmmm.
> I think I still have some confusion regarding all the terminology used
> in Mac development circles. Perhaps you can confirm that I've got the
> terms right:
>
> * Quartz: The OS X GUI.
> * Aqua: The newest API for Quartz.
> * Carbon: A "Classic" API for porting to Quartz quickly.
> * Classic: That old pre OS X non-Unix dreck
Close.
* Quartz: The OS X display server.
* Aqua: The OS X GUI.
* Cocoa: The "new" (it's really good old OpenStep) Objective-C/Java API
* Carbon: The traditional Mac API.
* Classic: An OS 9 system running in a little virtual machine.
Carbon is actually a perfectly fine procedural API, which also makes
it much easier to call from languages besides Obj-C or Java. I
haven't checked out the recent developments in OpenMCL's Objective-C
bridge, though, so maybe Cocoa is easy to use from Lisp now.
> I would actually be interested in having Aqua work. Rather, I would
> like to develop applications that are portable between Unix and Mac OS
> X with the appropriate native look and feel. I would also like this
> to work better than what Sun did with AWT/Swing for Java.
The easiest way to do that is probably to use LispWorks. Their CAPI
library is supposed to provide a native look-and-feel, and from the
screenshots I've seen, it does. It's $1000 on both Linux and OS X.
If you want to use a Free lisp, you can either abstract away the GUI,
and port that part to both systems; or you could port one of the many
Unix GUI toolkits to OS X.
> Proper and portable threading support in CL would also be nice because
> dual CPU systems are likely to only get more popular over time and it
> would be nice to take advantage of multiple CPUs.
Proper, shmoper, you seem to have forgotten that you're on Unix -- use
fork(2) :)
Actually, if you do want to use threads on the Mac, I'd recommend the
Carbon API. OpenStep didn't have threads, so Cocoa still has some
thread related bugs. Maybe they're all gone in Panther, but they
weren't in Jaguar.
> Because I am easily distracted by shiny things, I am still a neophyte
> Lisp programmer. I have bought into the hype that Lisp is The True
> Language for computer programming though.
Oh god, and you're using a Mac! I don't think I got any work done for
the first month I had mine, and I'm still prone to distraction. OS X
is one big shiny thing.
> My background is with C++ for compiled languages and Perl for
> scripting, so I probably have certain biases.
I might get strung up for this, but talking over a pipe to an
Objective-C process for UI works pretty damn well on OS X. And if you
use Objective-C for the kinds of things they mean you to use it for,
it's really really productive. Not quite up to Lisp or Smalltalk (you
still need to edit-compile-link-debug), but heckof good nonetheless.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> I might get strung up for this, but talking over a pipe to an
> Objective-C process for UI works pretty damn well on OS X.
Heh, I thought I was the only one using this horrible hack. Having tried
various ways to get MIDI support in MCL I finally punted and wrote a
little C++ stub that served up an ascii interface over a socket. It's
ugly, but it does work.
E.
From: David Steuber
Subject: Re: Kudos to Andrew Choi and other Mac OS X porters
Date:
Message-ID: <874qyo7h7t.fsf@verizon.net>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> David Steuber <·············@verizon.net> writes:
>
> > I never expected to use a 12" laptop as a substitute for a desktop
> > system.
>
> Nor did I -- but I seem to be using it more and more like one. It's
> so quiet, and the fullsized keyboard makes it possible. I could use a
> linux box (whirrrr), the Sun (WHIRRRRR), or the iBook (...). Hmmm.
The noise is my biggest issue. And even the little 12" PowerBook has
a rather good keyboard. To tell you the truth, I prefer it over the
Microsoft Natural keyboard.
> Close.
>
> * Quartz: The OS X display server.
> * Aqua: The OS X GUI.
> * Cocoa: The "new" (it's really good old OpenStep) Objective-C/Java API
> * Carbon: The traditional Mac API.
> * Classic: An OS 9 system running in a little virtual machine.
>
> Carbon is actually a perfectly fine procedural API, which also makes
> it much easier to call from languages besides Obj-C or Java. I
> haven't checked out the recent developments in OpenMCL's Objective-C
> bridge, though, so maybe Cocoa is easy to use from Lisp now.
OK. Thanks for clearing that up for me. It could always come up in
the technical portion of a job interview, should I be so lucky, and it
would be *most* embarrassing to confuse those points.
> The easiest way to do that is probably to use LispWorks. Their CAPI
> library is supposed to provide a native look-and-feel, and from the
> screenshots I've seen, it does. It's $1000 on both Linux and OS X.
I'm sure LispWorks is great, but I'm afraid that price is out of my
league. I'll have to stick with a Free Lisp and take what I can get.
SBCL is sounding better and better with the recommendations I am
hearing.
> > Proper and portable threading support in CL would also be nice because
> > dual CPU systems are likely to only get more popular over time and it
> > would be nice to take advantage of multiple CPUs.
>
> Proper, shmoper, you seem to have forgotten that you're on Unix -- use
> fork(2) :)
Yeah, let's fire up another 20MB process just to do some background
job. It's the Unix Way (tm).
> Actually, if you do want to use threads on the Mac, I'd recommend the
> Carbon API. OpenStep didn't have threads, so Cocoa still has some
> thread related bugs. Maybe they're all gone in Panther, but they
> weren't in Jaguar.
I might be able to get Panther by year end. I'm not in a situation
where I need legacy support for anything I do. Still, it's something
to consider. Maybe Panther hasn't fixed things yet either.
> > Because I am easily distracted by shiny things, I am still a neophyte
> > Lisp programmer. I have bought into the hype that Lisp is The True
> > Language for computer programming though.
>
> Oh god, and you're using a Mac! I don't think I got any work done for
> the first month I had mine, and I'm still prone to distraction. OS X
> is one big shiny thing.
No kidding. Shiny things are everywhere around here so I get nothing
done.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
David Steuber <·············@verizon.net> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Proper, shmoper, you seem to have forgotten that you're on Unix -- use
> > fork(2) :)
>
> Yeah, let's fire up another 20MB process just to do some background
> job. It's the Unix Way (tm).
Certainly there are times when threads are useful, but Unix processes
are fairly lightweight -- they're nothing like Windows processes.
According to a naive fork-bomb test on this little 500MHz Sun
Blade-100 here, forking a 15MB CMUCL process takes about 0.01 seconds.
Of course, with copy-on-write, the size of the process isn't that big
of a deal.
> > Actually, if you do want to use threads on the Mac, I'd recommend the
> > Carbon API. OpenStep didn't have threads, so Cocoa still has some
> > thread related bugs. Maybe they're all gone in Panther, but they
> > weren't in Jaguar.
>
> I might be able to get Panther by year end. I'm not in a situation
> where I need legacy support for anything I do. Still, it's something
> to consider. Maybe Panther hasn't fixed things yet either.
Rereading my quote above, I didn't mean to imply that anything will be
fixed in Panther -- I have no idea. I hope the threading bugs will be
gone, but I have no reason to think they will.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>, Thomas F. Burdick
<···@famine.OCF.Berkeley.EDU> wrote:
> Carbon is actually a perfectly fine procedural API, which also makes
> it much easier to call from languages besides Obj-C or Java. I
> haven't checked out the recent developments in OpenMCL's Objective-C
> bridge, though, so maybe Cocoa is easy to use from Lisp now.
It's not exactly easy, but it's not too hard. It's very easy to get a
Cocoa listener on the screen; making an app that is packaged properly
for installing in an arbitrary place on an OSX system is harder, mostly
because it's obscure rather than actually difficult. I'm working on
some stuff that I hope will increase OpenMCL's utility for certain
purposes and onne side effect of that effort is that I've got a little
project that is basically a template lisp app that is easy to install
anywhere and run, and that is easy to mutate into whatever app you want
by writing lisp code.
Before anybody asks me for it, it's not ready yet. I'm still in the
middle of making it possible to build the app with or without the
embedded lisp listener out of the same code base. I did do a test port
of a Jython GUI app to OpenMCL, though, and got it working in a couple
hours, so that was promising.
> > I would actually be interested in having Aqua work. Rather, I would
> > like to develop applications that are portable between Unix and Mac OS
> > X with the appropriate native look and feel. I would also like this
> > to work better than what Sun did with AWT/Swing for Java.
>
> The easiest way to do that is probably to use LispWorks. Their CAPI
> library is supposed to provide a native look-and-feel, and from the
> screenshots I've seen, it does. It's $1000 on both Linux and OS X.
As I said elsewhere, I tested it anndd found it good. $3000 is a lot of
money, but maybe not too much if you really want thee same code to run
on OSX, Linux, and Windows. I'm still thinking about springing for it.
> Oh god, and you're using a Mac! I don't think I got any work done for
> the first month I had mine, and I'm still prone to distraction. OS X
> is one big shiny thing.
That's for sure.
> > My background is with C++ for compiled languages and Perl for
> > scripting, so I probably have certain biases.
>
> I might get strung up for this, but talking over a pipe to an
> Objective-C process for UI works pretty damn well on OS X. And if you
> use Objective-C for the kinds of things they mean you to use it for,
> it's really really productive. Not quite up to Lisp or Smalltalk (you
> still need to edit-compile-link-debug), but heckof good nonetheless.
I tried that too, and it workeed pretty well. Heck I tried it for an ML
app as well as for a Lisp one; worked great either way. There are even
some advantages to it, as it forces a clean separation of presentation
and model. But I was obsessed with writing all my code in Lisp, so I
chose to mess with writing Cocoa apps in OpenMCL rather than pursuinng
that route.
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> mikel <·····@evins.net> writes:
>
> > I use openmcl and ilisp habitually, using the same emacs you're using
> > (but on a PowerBook with a much larger screen :-)).
>
> Do you need a pointer to a self help group? ;-)
>
> I never expected to use a 12" laptop as a substitute for a desktop
> system. If I did, and I had the cash, I would have the 17" stuffed
> with all the bells and whistles. I'm now wondering when Apple will
> offer the G5 in its PowerBook lineup and when they will have the nerve
> to do what no one has done before: offer a dual CPU notebook
> computer.
Supposedly in about a year, but that's just rumors.
> > It's possible to build apps with openmcl that use the Cocoa UI
> > framework--not easy yet, but possible. There are efforts underway to
> > make it easier, and the latest sources from cvs on the 0.14 branch have
> > some of that work in them (as well as native thread support). Also, the
> > lastest McCLIM sources build against the latest openmcl cvs sources
> > (0.14 branch) and the examples work under Apple's X11. There are
> > efforts to port Portable Hemlock and to build a native Aqua backend for
> > McCLIM.
>
> I think I still have some confusion regarding all the terminology used
> in Mac development circles. Perhaps you can confirm that I've got the
> terms right:
>
> * Quartz: The OS X GUI.
Quartz is the 2D display server and architecture.
> * Aqua: The newest API for Quartz.
Aqua is the name of the GUI--that is, the visual and interaction design.
> * Carbon: A "Classic" API for porting to Quartz quickly.
Carbon is a bunch of C functions, types, and constants that provide an
API for talking to Quartz and the various UI and other frameworks.
Carbon is a flat C API; there is a second API called Cocoa that is
based on Objective C classes and methods, and the Objective C runtime.
Doesn't matter a whole lot which one you use; I've written several
small test apps in OpenMCL using each. Basically, it's easier to map
lisp code to the Carbon API, but it's easier to get more of the UI up
and working using Cocoa (assuming you've figured out the right
incantations to get the runtime up an working). Bottom line is it's
less than a hundred lines of lisp to get a functioning window on the
screen either way.
> * Classic: That old pre OS X non-Unix dreck
Classic is an emulation box for the pre-Unix Mac OS 9.
>
> I have no idea how much stuff Panther will end up breaking. Hopefully
> the answer is none of the above. I personally don't much care if
> apple supports the old applications or not, but some people seem to
> think that I shouldn't be a solipsist. Since they only exist in my
> imagination, I'm not sure I should worry about what they think ;-)
>
> > Any of the abovementioned efforts would be useful places to spend
> > hacking efforts. I don't know if the McCLIM listener works on openmcl,
> > but it would also be kind of cool to get that working.
>
> I would actually be interested in having Aqua work. Rather, I would
> like to develop applications that are portable between Unix and Mac OS
> X with the appropriate native look and feel. I would also like this
> to work better than what Sun did with AWT/Swing for Java.
Easiest way to do this is to buy Lispworks for each platform and use
CAPI. 'Course it's about a thousand bucks a copy. I thought about it; I
tested the Mac OSX version and found it mighty fine, but I like OpenMCL
and I like hacking on it, so I'm trying to make some things to make it
more useful. Still might buy Lispworks, though.
> Proper and portable threading support in CL would also be nice because
> dual CPU systems are likely to only get more popular over time and it
> would be nice to take advantage of multiple CPUs. Even so, the use of
> threading also simplifies application design when the appropriate
> abstraction is available. I think Java's threading model is actually
> well done unlike AWT/Swing. I prefer the Win32 API for threading, but
> I don't program to that anymore for now. I have not yet experienced
> the joy of pthreads. I have heard that the current pthread libs for
> Linux (or perhaps all GNU libc based systems) are rather ungood. I
> certainly don't care for threads looking like additional processes
> with the ps command.
Gary made an interface to native threads on OSX in OpenMCL 0.14. It
might be worth checking out, just because it's there and it's free.
I've only messed with it a little so far, so I'm no source of useful
information.
> Because I am easily distracted by shiny things, I am still a neophyte
> Lisp programmer. I have bought into the hype that Lisp is The True
> Language for computer programming though.
I never did that. I just woke up one day and discovered that I solved
all my programming problems in Lisp, even if I had to write them in
something else. :-)
From: Duane Rettig
Subject: 64-bit G5? (was: Kudos to Andrew Choi and other Mac OS X porters)
Date:
Message-ID: <43ceaem65.fsf@beta.franz.com>
David Steuber <·············@verizon.net> writes:
> The other thing is that on my Debian system, I am setup for CMUCL. I
> could just get OpenMCL and install ilisp. Or, I can see how much work
> it would take to port CMUCL over to the PPC line. With the new
> PPC970s now coming out, I wish I could afford a G5. That looks like
> the future.
Well, if by "the future" you mean 64-bit, don't get your hopes up
for at least a year or so. As an Apple lover myself, I made that
mistake, and committed to do a port of our product to the new Apple
G5. It was to be an easy port, since we already have a version of
Allegro CL on the Power3/Power4 architectures on AIX5. We got our
G5 machine on 9/11, and I had our sysadmin give it a hostname of "nyc",
both as a tribute to the date, and to denote our first "big apple".
We timed it, and it seemed fairly fast; it was a 1.6 Ghz, and it was
about the same speed in our benchmarks as the AMD Athlon of the same
frequency, and was only slower than two other machines; a 1.8 Ghz
AMD Athlon, and a 1.4 Ghz AMD Opteron (the 64-bit AMD). So I dug in.
By Friday the 12th, I had come to the terrible realization that this
G5 was going to be performing very few 64-bit instructions, because
there was absolutely no 64-bit support for it in the operating system.
(Yeah, they advertize that they support a 64-bit long long C type,
but if you've ever seen assembler of these things being passed around,
as opposed to the true 64-bit calling sequence, you'd wonder why
anyone even bothered with them).
I tried all gcc options, and our sysadmin found some obscure messages
on an Apple site about MacOSX not having real 64-bit support, and that
such support had not yet been planned.
By Monday we had packed nyc up and shipped it back for a refund.
We already have several 32-bit Apples which are adequate for our
needs and didn't need an overpowered 64-bit machine suffocating in
a 32-bit operating system.
Perhaps you can tell by some of my phrases that I'm a little
disgruntled. Actually, I'm mostly just disappointed; as an Apple
fan I was looking forward to some good speed wars between the G5
and the Opteron (the AMD64). Oh, yeah; it's me playing against
myself alright (picture me as Geri, the old man in the little
Pixar snippet just before "A Bug's Life", who plays himself in
a game of chess, and even manages to cheat...). I win every time!
But with no _real_ 64-bit Apple, I'm cheated out of my game!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> By Friday the 12th, I had come to the terrible realization that this
> G5 was going to be performing very few 64-bit instructions, because
> there was absolutely no 64-bit support for it in the operating system.
> (Yeah, they advertize that they support a 64-bit long long C type,
> but if you've ever seen assembler of these things being passed around,
> as opposed to the true 64-bit calling sequence, you'd wonder why
> anyone even bothered with them).
>
> I tried all gcc options, and our sysadmin found some obscure messages
> on an Apple site about MacOSX not having real 64-bit support, and that
> such support had not yet been planned.
>
> By Monday we had packed nyc up and shipped it back for a refund.
> We already have several 32-bit Apples which are adequate for our
> needs and didn't need an overpowered 64-bit machine suffocating in
> a 32-bit operating system.
>
I'm sorry to hear about your experiences with the G5; it's true that
Apple has not yet provided a 64-bit operating system for the G5, but
there has never been a 64-bit Darwin or NeXTStep operating system in the
past, so it will take them the usual amount of time to go "truly"
64-bit. I recieved my dual G5 as of last week, and I belive that your
decision to return the G5 might have been premature: OpenMCL and SBCL
both seem to crawl on the G5 (especially when compared to G4s which
perform quite well). This indicates that optimization is probably
necessary to make the G5 run at its full speed, even if it is only
running in 32-bit mode. Perhaps ACL does not share these same problems,
but I would have thought it wise to see if any optimization could be
done even when only running in 32-bit mode.
I am eagerly awaiting a 64-bit Linux or NetBSD kernel for the G5, but
64-bit PowerPC seems to require aligned load/stores which would defeat
or hamper lowtagging. I'm hopeful that some creative solution can be
found to provide 64-bit free lisp on the G5.
From: Duane Rettig
Subject: Re: 64-bit G5? (was: Kudos to Andrew Choi and other Mac OS X porters)
Date:
Message-ID: <44qypu7s9.fsf@beta.franz.com>
Brian Mastenbrook <··············@indiana.edu> writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
>
> > By Friday the 12th, I had come to the terrible realization that this
> > G5 was going to be performing very few 64-bit instructions, because
> > there was absolutely no 64-bit support for it in the operating system.
> > (Yeah, they advertize that they support a 64-bit long long C type,
> > but if you've ever seen assembler of these things being passed around,
> > as opposed to the true 64-bit calling sequence, you'd wonder why
> > anyone even bothered with them).
> >
> > I tried all gcc options, and our sysadmin found some obscure messages
> > on an Apple site about MacOSX not having real 64-bit support, and that
> > such support had not yet been planned.
> >
> > By Monday we had packed nyc up and shipped it back for a refund.
> > We already have several 32-bit Apples which are adequate for our
> > needs and didn't need an overpowered 64-bit machine suffocating in
> > a 32-bit operating system.
> >
>
> I'm sorry to hear about your experiences with the G5; it's true that
> Apple has not yet provided a 64-bit operating system for the G5, but
> there has never been a 64-bit Darwin or NeXTStep operating system in the
> past, so it will take them the usual amount of time to go "truly"
> 64-bit.
I understand that, and that's why we didn't bother keeping it.
It really depends on your understanding of what "the usual amount
of time" is. (for example, how long have Microsoft been porting
their OS to 64-bit platforms? Answer: since before DEC went under).
> I recieved my dual G5 as of last week, and I belive that your
> decision to return the G5 might have been premature: OpenMCL and SBCL
> both seem to crawl on the G5 (especially when compared to G4s which
> perform quite well). This indicates that optimization is probably
> necessary to make the G5 run at its full speed, even if it is only
> running in 32-bit mode.
I don't see why that indicates that sending it back was premature; if
they get a true 64-bit os out in a year, then by Moore's law we'll
pay the same price and get a machine that is twice as fast, with an
even faster operating system on it!
> Perhaps ACL does not share these same problems,
> but I would have thought it wise to see if any optimization could be
> done even when only running in 32-bit mode.
Allegro CL ran fine on it, and it felt snappy enough. But I was
so disapponted, I didn't bother running benchmarks on it. I'm sure
others will, eventually.
> I am eagerly awaiting a 64-bit Linux or NetBSD kernel for the G5, but
> 64-bit PowerPC seems to require aligned load/stores which would defeat
> or hamper lowtagging.
Well, it has to be worked around, but it wasn't the first architecture
to do this, nor will it be the last; there are compromises that must
be made when extending an instruction set to 64 bits, while holding the
instruction _size_ to 32 bits. The low order bits are the most logical
bits to leave off of the displacement calculations because sizes are
bigger, and displacements are going to overflow in fewer number of
words off of the addressing register.
The workarounds are fairly easy, and shouldn't create any pipeline
issues (although an extra register is needed) - on the HP PA-RISC-2.0,
which allows indexed loads, we preload such an extra register with the
displacement and then perform the access:
CL-USER(3): (disassemble
(compile
(defun foo (x)
(declare (optimize speed (safety 0) (debug 0)))
(bar x))))
Warning: While compiling these undefined functions were referenced: BAR.
;; disassembly of #<Function FOO>
;; formals: X
;; constant vector:
0: BAR
;; code start: #x800000100116c0c8:
0: 340b008e [ldo] ldi #x47,r11
4: 0e2b00c8 ldd r11(s0,r17),r8 BAR
8: e920d000 bve (r9)
12: 34040002 [ldo] ldi #x1,r4
CL-USER(4):
and on the Power3/Power4 architectures, we calculate the address into the
temporary register and then load from directly under it:
CL-USER(2): (disassemble
(compile
(defun foo (x)
(declare (optimize speed (safety 0) (debug 0)))
(bar x))))
Warning: While compiling these undefined functions were referenced: BAR.
;; disassembly of #<Function FOO>
;; formals: X
;; constant vector:
0: BAR
;; code start: #x7000010012550d8:
0: 7ea903a6 [mtspr] mtctr r21 "symbol_trampoline"
4: 3a370046 cal r17,70(r23) (BAR)
8: ea910000 ld r20,0(r17) BAR
12: 3a000001 [cal] lil r16,1
16: 4e800420 bctr
CL-USER(3):
> I'm hopeful that some creative solution can be
> found to provide 64-bit free lisp on the G5.
Nothing is ever free; someone will have to do the work :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: David Steuber
Subject: Re: 64-bit G5? (was: Kudos to Andrew Choi and other Mac OS X porters)
Date:
Message-ID: <87y8w2nl06.fsf@verizon.net>
Duane Rettig <·····@franz.com> writes:
> By Monday we had packed nyc up and shipped it back for a refund.
> We already have several 32-bit Apples which are adequate for our
> needs and didn't need an overpowered 64-bit machine suffocating in
> a 32-bit operating system.
>
> Perhaps you can tell by some of my phrases that I'm a little
> disgruntled. Actually, I'm mostly just disappointed; as an Apple
> fan I was looking forward to some good speed wars between the G5
> and the Opteron (the AMD64). Oh, yeah; it's me playing against
> myself alright (picture me as Geri, the old man in the little
> Pixar snippet just before "A Bug's Life", who plays himself in
> a game of chess, and even manages to cheat...). I win every time!
> But with no _real_ 64-bit Apple, I'm cheated out of my game!
I can't tell you how disappointed I am to hear that. I had the
impression that Apple had put in a patch for GCC 3.3 to have full 64
bit support. I thought for sure that Panther would be compiled in 64
bit, along with all the bundled applications.
A friend of mine got a dual G5 running at 2Ghz a couple weeks back.
Just yesterday he told me he was running 10.2.8 on it. This was after
I asked him how he liked the new Panther release. I was not exactly
happy to hear that either.
What good is the fancy hardware without the compiler support? The
fact that it is a bit faster is not such a big deal to me. Sure, I
love speed. I wish Mazda put the three rotor Wankel in their RX-8 for
major horse power off the showroom floor (now that would be zoom
zoom). However, for most tasks, my computers wait for me. The load
average on my Celleron 566Mhz powered web server is 0.00 0.00 0.00.
It is no higher on my dual 1.533Mhz Athalon.
I was (and still am) looking forward to an absurdly large addressable
memory space. Oh well. I guess this gives me some time to catch up.
OK, so I was also looking forward to even more speed.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
Duane Rettig <·····@franz.com> writes:
> [...]
> By Friday the 12th, I had come to the terrible realization that this
> G5 was going to be performing very few 64-bit instructions, because
> there was absolutely no 64-bit support for it in the operating system.
> (Yeah, they advertize that they support a 64-bit long long C type,
> but if you've ever seen assembler of these things being passed around,
> as opposed to the true 64-bit calling sequence, you'd wonder why
> anyone even bothered with them).
> [...]
> Perhaps you can tell by some of my phrases that I'm a little
> disgruntled. Actually, I'm mostly just disappointed; as an Apple
> fan I was looking forward to some good speed wars between the G5
> and the Opteron (the AMD64). Oh, yeah; it's me playing against
> myself alright (picture me as Geri, the old man in the little
> Pixar snippet just before "A Bug's Life", who plays himself in
> a game of chess, and even manages to cheat...). I win every time!
> But with no _real_ 64-bit Apple, I'm cheated out of my game!
Well your disappointment is perfectly understandable, but one could
consider (and perticularly in the "Apple" environment, if not in the
"NeXT" environment), that the OS is merely another (quite useless if
at all suffered) application. I mean that if the OS stays 32-bit,
that does not prevent user code to be 64-bit and be very fast. Of
course, the first thing to have is a 64-bit compiler, for example, a
64-bit LISP compiler ;-)
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
From: Duane Rettig
Subject: Re: 64-bit G5? (was: Kudos to Andrew Choi and other Mac OS X porters)
Date:
Message-ID: <4vfr5sqd7.fsf@beta.franz.com>
[I already answered some issues further down this thread, but wanted
to touch on this serious misunderstanding]
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Well your disappointment is perfectly understandable, but one could
> consider (and perticularly in the "Apple" environment, if not in the
> "NeXT" environment), that the OS is merely another (quite useless if
> at all suffered) application.
This would be a naiive consideration. It is true that some parts of
an operating system can be considered as user-mode programming, and
as I understand it there was even movement afoot several years ago to
make MkLinux (a linux user-mode kernel on a Mach microkernel) to be
the starting point for the new MacOS at the time (it was always being
promoted as MacOS X) and there may indeed still be a microkernel
underneath the BSD which prevailed. But however you look at it,
there are certain things that are necessary, not the least of which
are agreement on what an address looks like:
If I am moving bits around in a register, and use it to access memory,
and if that memory is not mapped in which causes a page fault, how many
bits is the page-fault handler going to look at to determine what address
the user wants? If I have #x0000000012345678 in my register and I
then do an 8-byte load, will the page-translation system distinguish
this address from, say, #x1111111112345678, or will it return the
same data?
This part of an operating system - memory management - is at least one
piece which is critical to any program's successful operation.
> I mean that if the OS stays 32-bit,
> that does not prevent user code to be 64-bit and be very fast. Of
> course, the first thing to have is a 64-bit compiler, for example, a
> 64-bit LISP compiler ;-)
If our Lisp were an operating-system unto itself, then yes, this would
be possible. But it's not; our Lisp interfaces to libc functionality
and to system services, to provide full access to such services. It
would not be easy to use a 64-bit lisp whose calls to stat() always
returned 32-bit values. And what if I were to pass the address of a
buffer to read() which was above the 4Gb mark; how happy would I be
if read() didn't put the data where I expected it to send it?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In an attempt to throw the authorities off his trail, Pascal Bourguignon <····@thalassa.informatimago.com> transmitted:
> Well your disappointment is perfectly understandable, but one could
> consider (and perticularly in the "Apple" environment, if not in the
> "NeXT" environment), that the OS is merely another (quite useless if
> at all suffered) application. I mean that if the OS stays 32-bit,
> that does not prevent user code to be 64-bit and be very fast. Of
> course, the first thing to have is a 64-bit compiler, for example, a
I would think it rather a challenge for user code to be "64 bit" if
the OS does not support that.
It might be quite reasonable for the graphical environment to remain
"32 bit-oriented," as it isn't too likely that we'll have to reference
displays with widths or heights of more than 2 billion pixels.
But if the OS limits you to 4GB of memory per process, I don't see how
"user code" can overcome this. That is probably the most vital aspect
of 64 bit support, in these "memory-bloated" days.
--
(reverse (concatenate 'string "gro.mca" ·@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"You can not reason a man out of a position he did not reach through
reason"
Christopher Browne <········@acm.org> writes:
[...]
> But if the OS limits you to 4GB of memory per process, I don't see
> how "user code" can overcome this. That is probably the most vital
> aspect of 64 bit support, in these "memory-bloated" days.
What about access to 64-bit registers? I'm sure there are some
applications where these could be useful.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> Christopher Browne <········@acm.org> writes:
> [...]
> > But if the OS limits you to 4GB of memory per process, I don't see
> > how "user code" can overcome this. That is probably the most vital
> > aspect of 64 bit support, in these "memory-bloated" days.
>
> What about access to 64-bit registers? I'm sure there are some
> applications where these could be useful.
Some of the staff and management here at Franz had the same kinds
of questions. I think that the best way to show how this doesn't
help is to show you some actual code, which will speak for itself
very loudly. This is the message I sent to my team and management
on Sept 12 after my sysadmin and I had been going around for a
while on how to get the gcc to generate 64-bit code. The mail is
verbatim, except that I've bleeped out the hostname of our power3
box:
=====
>> >> >> Here's some info that you might be able to use to move things along a
>> >> >> little bit. To get the compiler to generate 64-bit code, pass these
>> >> >> options:
>> >>
>> >> This doesn't cause any 64-bit code to be generated.
>>
>> It does if you use a 64-bit data type (long long).
Heh, heh. Even before I tried this I could tell that this was
marketing slime from Apple to hide the fact that they truly don't
have 64-bits yet. In a 64-bit port, a long is a 64-bit value (also
any pointer values), and a long long is unnessary or it is the same
as long. The fact that long is 32 bits (likely the same for char *,
though I haven't tested it) make this system so far incapable of
supporting a 64-bit lisp.
Let's look at the difference, by going to <power3>:
[<power3> /acl/duane/test 24] cat test1.c
long
func2(long a, long b)
{
return a*b+1;
}
[<power3> /acl/duane/test 25] cc -S -q64 test1.c
[<power3> /acl/duane/test 26] cat test1.s
[ a lot of cruft removed ...]
# .text section
.file "test1.c"
.machine "ppc64"
.csect H.4.NO_SYMBOL{PR}
.func2: # 0x0000000000000000 (H.4.NO_SYMBOL)
stdu SP,-128(SP)
std r3,176(SP)
std r4,184(SP)
ld r3,176(SP)
ld r4,184(SP)
mulld r3,r3,r4
addi r3,r3,1
addi SP,SP,128
bclr BO_ALWAYS,CR0_LT
[ More stuff removed ... ]
[<power3> /acl/duane/test 27]
OK, notice the two std instructions?
std r3,176(SP)
std r4,184(SP)
An important point is that the arguments are passed fully in registers
r3 and r4, all 64 bits in each one.
Compare this with nyc using long longs:
[nyc.franz.com /storage1/acl/duane/test 60] cat test1.c
long long
func2(long long a, long long b)
{
return a*b+1;
}
[nyc.franz.com /storage1/acl/duane/test 61] cc -S -mcpu=970 -mtune=970 -mpowerpc64 test1.c
[nyc.franz.com /storage1/acl/duane/test 62] cat test1.s
.section __TEXT,__text,regular,pure_instructions
.align 2
.align 2
.globl _func2
.section __TEXT,__text,regular,pure_instructions
.align 2
_func2:
stw r30,-8(r1)
stwu r1,-64(r1)
mr r30,r1
mr r0,r3
mr r2,r4
stw r0,32(r30)
stw r2,36(r30)
mr r0,r5
mr r2,r6
stw r0,40(r30)
stw r2,44(r30)
ld r2,32(r30)
ld r0,40(r30)
mulld r2,r2,r0
addi r2,r2,1
mr r0,r2
srdi r0,r0,32
mr r3,r0
mr r4,r2
lwz r1,0(r1)
lwz r30,-8(r1)
blr
[nyc.franz.com /storage1/acl/duane/test 63]
In this case r3 and r4 constitute the first long long argument, and
r5/r6 make the second argument. If you follow it through, a 64-bit
value is being built from the two 32-bit values each, and the 64-bit
instructions are used intermediately to calculate the result (which
is then split up into two 32-bit values again to pass back through r3
and r4, rather than one 64-bit value in r3).
This 64-bit port is looking more and more like a non-starter...
=====
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
If I understand correctly, you were doing your tests with GCC on a
fairly new processor. Perhaps what Apple (or IBM) needs to do is tune
the machine description file for the new processor so that GCC will
generate better code? Or has that step already been done?
--
Geoffrey S. Knauth | http://knauth.org/gsk
Duane Rettig <·····@franz.com> wrote:
> David Magda <··················@ee.ryerson.ca> writes:
> > What about access to 64-bit registers? I'm sure there are some
> > applications where these could be useful.
>
> Some of the staff and management here at Franz had the same kinds
> of questions. I think that the best way to show how this doesn't
> help is to show you some actual code, which will speak for itself
> very loudly. This is the message I sent to my team and management
> on Sept 12 after my sysadmin and I had been going around for a
> while on how to get the gcc to generate 64-bit code. The mail is
> verbatim, except that I've bleeped out the hostname of our power3
> box:
After a long battle with technology,·····@knauth.org (Geoffrey S. Knauth), an earthling, wrote:
> If I understand correctly, you were doing your tests with GCC on a
> fairly new processor. Perhaps what Apple (or IBM) needs to do is
> tune the machine description file for the new processor so that GCC
> will generate better code? Or has that step already been done?
Bzzt. Wrong.
GCC has been supporting 64 bit PPC platforms for a while now, and has
been supporting other 64 bit platforms for probably a decade.
Blaming GCC for the design restrictions Apple decided to go with in
their OS solves nothing.
No, what is happening is that Apple designed MacOS-X as a 32 bit OS,
and it _isn't_ a quick 15 minute port to get it to 64 bits.
They surely ARE better off than Microsoft was; Microsoft has been
porting Windows to be a "64 bit" system since the days Digital donated
their core OS developers to Microsoft, and there still isn't a 64 bit
system being hawked there.
Changing MacOS-X to "64 bit" would have two notable breakages:
- Applications currently written for a 32 bit environment would
likely get confused;
- There is little sense in changing the graphical subsystem to "64
bits" as you generally don't need _huge_ amounts of memory or
64 bit dynamic range to express 'graphical stuff.'
Since Apple is using a lot of BSD code that is known to work on 64 bit
systems, and is using GCC, known to generate 64 bit code (I was
compiling 64 bit PPC code yesterday using GCC, albeit on AIX), they
should at least have a half-decent base that they know is feasible to
port. Microsoft never had that.
But the notion that they'll be jumping to a full 64 bits of support on
the addressing side any time soon would seem deluded. It took
everyone else years to accomplish that.
--
output = reverse("gro.gultn" ·@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/rdbms.html
"I have never seen the inside of the building at Microsoft where the
top executives hang out, but I have this fantasy that in the hallways,
at regular intervals, big red alarm boxes are bolted to the wall. Each
contains a large red button protected by a windowpane. A metal hammer
dangles on a chain next to it. Above is a big sign reading: IN THE
EVENT OF A CRASH IN MARKET SHARE, BREAK GLASS." -- Neal Stephenson
> Changing MacOS-X to "64 bit" would have two notable breakages:
> - Applications currently written for a 32 bit environment would
> likely get confused;
Not at all. Solaris does just fine with a mixed 32-bit/64-bit ABI.
When they moved from SPARC v8 to SPARC v9, there was little hoopla.
They recompiled the kernel for 64-bit support, added a set of legacy
32-bit system call entry points, and offered both 32-bit and 64-bit
compiled libraries. The key advantage for them was that svr4 was
designed to be portable, so it wasn't as much work to get Solaris
64-bit clean.
> should at least have a half-decent base that they know is feasible to
> port. Microsoft never had that.
Not at all! The Windows NT kernel was designed from the bottom up to
be fully portable. It ran, initially, on MIPS, x86, PowerPC, and
Alpha. Rumor has it that these lines are still maintained deep within
Redmond. Now, there has been a lot of bit-rot since Win2k (the Win2k
early previews were the last releases that ran on non-x86
architectures) but the guts haven't change all that much in XP.
>
> But the notion that they'll be jumping to a full 64 bits of support on
> the addressing side any time soon would seem deluded. It took
> everyone else years to accomplish that.
It took less than a year to port Linux to the Alpha. Of course, Apple
has more code to port, but they also have tons more engineering
resources, and are building off a base of largely 64-bit clean code.
NeXTStep had already been ported before, and much of the BSD stuff in
the kernel (added on top of 4.4BSD) is from the highly-portable NetBSD
Rayiner Hashem <·······@mindspring.com> wrote:
+---------------
| > Changing MacOS-X to "64 bit" would have two notable breakages:
| > - Applications currently written for a 32 bit environment would
| > likely get confused;
|
| Not at all. Solaris does just fine with a mixed 32-bit/64-bit ABI.
| When they moved from SPARC v8 to SPARC v9, there was little hoopla.
| They recompiled the kernel for 64-bit support, added a set of legacy
| 32-bit system call entry points, and offered both 32-bit and 64-bit
| compiled libraries.
+---------------
SGI's Irix did the same. All of the Irix 64-bit kernels (basically,
Irix 6.5 is 64-bit on all platforms *except* the O2) support running
user binaries compiled in any of the "-64", "-n32", or "-o32" ABIs.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> >> >> This doesn't cause any 64-bit code to be generated.
> >>
> >> It does if you use a 64-bit data type (long long).
>
> Heh, heh. Even before I tried this I could tell that this was
> marketing slime from Apple to hide the fact that they truly don't
> have 64-bits yet. In a 64-bit port, a long is a 64-bit value
There are perfectly good reasons for not doing that, such as source code
compatability with legacy (aka "broken") code that expects particular
sizes. I'm sure there is a *lot* of that out there.
> (also
> any pointer values), and a long long is unnessary or it is the same
> as long. The fact that long is 32 bits (likely the same for char *,
> though I haven't tested it) make this system so far incapable of
> supporting a 64-bit lisp.
Are the 64 bit *instructions* there in the CPU or not? Are the
registers 64 bit or not?
If they are, then what is preventing you, as a compiler vendor, from
using them?
Perhaps you'll need a different ABI to talk to OS code and libraries
than to your own code inside the application, but so what?
I really don't care what the C compiler calls various sized types -- all
portable code these days typedef's anything it cares about anyway. The
question is what can the hardware do?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
>
> > >> >> This doesn't cause any 64-bit code to be generated.
> > >>
> > >> It does if you use a 64-bit data type (long long).
> >
> > Heh, heh. Even before I tried this I could tell that this was
> > marketing slime from Apple to hide the fact that they truly don't
> > have 64-bits yet. In a 64-bit port, a long is a 64-bit value
>
> There are perfectly good reasons for not doing that, such as source code
> compatability with legacy (aka "broken") code that expects particular
> sizes. I'm sure there is a *lot* of that out there.
No, all 64-bit operating systems have the same size longs. It is
because longs are defined to be the same size as a pointer. There
is nothing wrong with defining a long long type (it would be the
same size as a long in a 64-bit system); it is when the claim
is made to have "64-bit support" when that in fact _only_ entails
such trivial things as long long types and access to the instructions-
that's marketing sleaze.
Face it. Apple simply weren't ready for a full 64-bit support on
their new 64-bit machines, but they decided to compete in that
arena anyway. I have noticed, however, that for the past two or
three months, there has been _very_ little mentioned about 64-bit-ness
in any of the advertisements for G5s in the Mac Magazines (at least,
much less than there had been several months ago).
> > (also
> > any pointer values), and a long long is unnessary or it is the same
> > as long. The fact that long is 32 bits (likely the same for char *,
> > though I haven't tested it) make this system so far incapable of
> > supporting a 64-bit lisp.
>
> Are the 64 bit *instructions* there in the CPU or not? Are the
> registers 64 bit or not?
Absolutely. What does that have to do with a 64-bit _system_?
Have you ever tried using 64-bit instructions, on a 64-bit
machine, but in a 32-bit system?
> If they are, then what is preventing you, as a compiler vendor, from
> using them?
Operating system support. I have no desire to try to recreate
the operating system under my product. I am part of a compiler
vendor, not an operating system vendor. (it would be interesting
to do, and is worthwhile when dealing with embedding, but we are
definitely not in the business of competing with operating system
vendors).
> Perhaps you'll need a different ABI to talk to OS code and libraries
> than to your own code inside the application, but so what?
You saw the code generation from my previous post. The abi is either
supported on the system or it is not. Currently, the 64-bit abi is
not, so if you want to execute instructions within the current MacOSX
system, you use the 32-bit abi.
But not only that; if you try addressing more than 32-bits within that
system, you'll either SEGV or wraparound, depending on how the
page fault handlers treat extra bits in the upper half of a register.
And address space is the most important reason for having 64 bits.
It's not like we don't run on the G5; Allegro CL (the 32-bit version)
ran perfectly happily on the G5 system. So on a 32-bit operating
system, we'll stick with our 32-bit product, and wait until they come
out with 64-bit support before we try to use 64-bit instructions.
> I really don't care what the C compiler calls various sized types -- all
> portable code these days typedef's anything it cares about anyway. The
> question is what can the hardware do?
OK. So when does your 64-bit Dylan ship on it?
:-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> writes:
> ...
> No, all 64-bit operating systems have the same size longs. It is
> because longs are defined to be the same size as a pointer.
i think you are mistaken here. it's probably a widely adopted
convention in the era of 32 bit machines, but the c99 standard has
added (iirc) a macro that defines the int type that can represent a
pointer (i have the manual at work, so can't look it up right now),
something that should help to make programs more portable in the long
run
> There
> is nothing wrong with defining a long long type (it would be the
> same size as a long in a 64-bit system); it is when the claim
> is made to have "64-bit support" when that in fact _only_ entails
> such trivial things as long long types and access to the instructions-
> that's marketing sleaze.
>
> Face it. Apple simply weren't ready for a full 64-bit support on
> their new 64-bit machines, but they decided to compete in that
> arena anyway. I have noticed, however, that for the past two or
> three months, there has been _very_ little mentioned about 64-bit-ness
> in any of the advertisements for G5s in the Mac Magazines (at least,
> much less than there had been several months ago).
i'm a little bit confused now. gcc has been ported to several 64 bit
architectueres already, and i think power4 or power5 is one of them.
are you saying that you couldn't find a C compiler that is able to
generate 64 bit code? or is it that apple has delivered a compiler
that is geared towards using 32 bit oriented calling conventions? how
difficult would it be to find a compiler that uses the 64 bit
architecture? did you check that out?
> ...
i suspect your systems for sparc and RS6000 are genuine 64 bit lisps,
so in your case it's probably just a question of adapting it to the G5
Mac?
hs
--
ceterum censeo SCO esse delendam
··@heaven.nirvananet (Hartmann Schaffer) writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> writes:
> > ...
> > No, all 64-bit operating systems have the same size longs. It is
> > because longs are defined to be the same size as a pointer.
>
> i think you are mistaken here. it's probably a widely adopted
> convention in the era of 32 bit machines, but the c99 standard has
> added (iirc) a macro that defines the int type that can represent a
> pointer (i have the manual at work, so can't look it up right now),
> something that should help to make programs more portable in the long
> run
Yes, I corrected myself in another article. The typedefs are intptr_t
and uintptr_t, and all architectures that we have do define it (even
MS). But every single one of the *nix boxes also define these in terms
of longs, and longs to be 64-bits, when compiling to a 64-bit binary.
> > There
> > is nothing wrong with defining a long long type (it would be the
> > same size as a long in a 64-bit system); it is when the claim
> > is made to have "64-bit support" when that in fact _only_ entails
> > such trivial things as long long types and access to the instructions-
> > that's marketing sleaze.
> >
> > Face it. Apple simply weren't ready for a full 64-bit support on
> > their new 64-bit machines, but they decided to compete in that
> > arena anyway. I have noticed, however, that for the past two or
> > three months, there has been _very_ little mentioned about 64-bit-ness
> > in any of the advertisements for G5s in the Mac Magazines (at least,
> > much less than there had been several months ago).
>
> i'm a little bit confused now. gcc has been ported to several 64 bit
> architectueres already, and i think power4 or power5 is one of them.
Yes, Power3 and up.
> are you saying that you couldn't find a C compiler that is able to
> generate 64 bit code?
Not at all. AIX 5.x compiler is gcc, and it generates the very nice
64-bit code you saw, when requested to do 64-bit compilations.
> or is it that apple has delivered a compiler
> that is geared towards using 32 bit oriented calling conventions?
Yes. In fact, the man pages for gcc on the G5 had the options for the
64-bit abi for aix (among others), but none of the options worked.
At first, I was trying those options out, thinking that Apple had
just used AIX style in compilation, since they had a similar abi
for the 32-bit calling convention. But nothing worked; all the options
I tried were invalid.
> how
> difficult would it be to find a compiler that uses the 64 bit
> architecture? did you check that out?
The compiler has to fit the operating system. The operating system
is clearly 32-bit. Therefore, until the operating system becomes
changed to support 64-bit binaries, it will be impossible to use
a 64-bit compiler in it.
It would also be impossible to use binaries compiled from AIX's
gcc on a Mac, since AIX compiles to an ELF format, and MacOSX
compiles to Mach-o format. They're incompatible.
> i suspect your systems for sparc and RS6000 are genuine 64 bit lisps,
> so in your case it's probably just a question of adapting it to the G5
> Mac?
In theory, yes, but the system's compiler and kernel have to support
it.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> The compiler has to fit the operating system. The operating system
> is clearly 32-bit. Therefore, until the operating system becomes
> changed to support 64-bit binaries, it will be impossible to use
> a 64-bit compiler in it.
And it sounds like it might be this way for some time. The
semi-reputable rumor mill[*] said that Apple was working on
transitional support for the 64-bit chip for Panther, so that people
could start taking advantage of it, but ditched the effort. Also,
some of the old-timers from NeXT left -- including the guy who was in
charge of the VM system. Oh, and they apparently don't want to do it
"the Sun way." That last part sounds particularly bad -- wasn't Sun's
transition to the SPARC v9 considered a success?
[*] Ie, the bay-area out-drinking-with-the-friend-of-someone-who-works-in-Cupertino
mill, not the websites.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Duane Rettig <·····@franz.com> writes:
>
> > The compiler has to fit the operating system. The operating system
> > is clearly 32-bit. Therefore, until the operating system becomes
> > changed to support 64-bit binaries, it will be impossible to use
> > a 64-bit compiler in it.
>
> And it sounds like it might be this way for some time. The
> semi-reputable rumor mill[*] said that Apple was working on
> transitional support for the 64-bit chip for Panther, so that people
> could start taking advantage of it, but ditched the effort. Also,
> some of the old-timers from NeXT left -- including the guy who was in
> charge of the VM system. Oh, and they apparently don't want to do it
> "the Sun way." That last part sounds particularly bad -- wasn't Sun's
> transition to the SPARC v9 considered a success?
Is Apple feeling suicidal or something? They introduced the G5 as a
64 bit machine. Well the Intel 80386 was a 32 bit machine. Fat lot
of good that did when running Dos 3.3 on it. The PC hardware geeks
are going to flame the G5 into the stone age.
Companies that are criticized for having only a 3% market share should
not be making such blunders. I am finding this more depressing by the
minute.
> [*] Ie, the bay-area out-drinking-with-the-friend-of-someone-who-works-in-Cupertino
> mill, not the websites.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
For another data point, the Gambit-C scheme compiler has had for many years
an implementation option to use 8-byte WORDs on 32-bit machines. This does
not give you access to more than 4GB of memory, but it does increase the
tag word size on vectors, so vectors are not limited to 16MB in this model,
and bignum arithmetic is faster, since it will use 32x32=>64 bit multiplies.
So this mode will lead to increased performance (at the cost of extra memory)
on a machine like the G5.
Unfortunately, this code has bit-rotted in the beta version of 4.0 :-<.
Brad
David Steuber <·············@verizon.net> wrote in message news:<··············@verizon.net>...
> Is Apple feeling suicidal or something? They introduced the G5 as a
> 64 bit machine. Well the Intel 80386 was a 32 bit machine. Fat lot
> of good that did when running Dos 3.3 on it. The PC hardware geeks
> are going to flame the G5 into the stone age.
>
> Companies that are criticized for having only a 3% market share should
> not be making such blunders. I am finding this more depressing by the
> minute.
I too am disappointed, and this will certainly hold Apple back in the
enterprise server, and high end scientific workstation market, but I
don't think Apple went to 64 bits for those sorts of customers.
Apple's core market is in Video, Photographic image manipulation, and
DTP. For these uses, 64 bit is only about allowing larger memory
address spaces per process, and the G5 lets you do that now.
PC hardware geeks will consider Apple's decision a disappointment, but
PC hardware geeks do not buy rooms full of high end Macs. Video
editing shops do.
Quoth ·······@mediaone.net (Raffael Cavallaro):
> I too am disappointed, and this will certainly hold Apple back in
> the enterprise server, and high end scientific workstation market,
> but I don't think Apple went to 64 bits for those sorts of
> customers.
No, I'm sure they didn't. If I want an "enterprise server," Apple is
NOT on the radar. IBM is, with eSeries. We're unhappy with our Suns,
so we're trying to get _away_ from that. It is eminently unclear what
one should consider buying from HP; neither Alpha nor PA-RISC seem
particularly viable. SGI MIPS is only barely on the map, and that on
the "scientific workstation" side.
> Apple's core market is in Video, Photographic image manipulation, and
> DTP. For these uses, 64 bit is only about allowing larger memory
> address spaces per process, and the G5 lets you do that now.
Hmm? From what I saw in Duane's comments, this isn't something that
MacOS-X supports, G5 or no. If they aren't supporting 64 bit
pointers, by default, then you have NOT got "larger memory address
spaces per process."
And this is all _quite_ disappointing. There are only two 64 bit
architectures that seem particularly viable at this point, x86-64 and
PPC. And in order to get 64 bit support on PPC, I either have to pay
BIG bucks to IBM, or hope that Linux or NetBSD support the hardware
well enough for me to scrape off MacOS-X in favor of them.
The reason to care about PPC is NOT Apple; it is IBM...
--
let name="aa454" and tld="freenet.carleton.ca" in name ^ ·@" ^ tld;;
http://cbbrowne.com/info/finances.html
Wiener's Law of Libraries:
There are no answers, only cross references.
Hi Christopher Browne,
>> Apple's core market is in Video, Photographic image manipulation, and
>> DTP. For these uses, 64 bit is only about allowing larger memory
>> address spaces per process, and the G5 lets you do that now.
>
> Hmm? From what I saw in Duane's comments, this isn't something that
> MacOS-X supports, G5 or no. If they aren't supporting 64 bit pointers,
> by default, then you have NOT got "larger memory address spaces per
> process."
I'm speculating here that Raffael's comment may imply that Apple has moved
the kernel space above 4GB, permitting a full 4GB of address space for
32-bit applications, which could be an improvement of 1-2GB.
Regards,
Adam
>>> Apple's core market is in Video, Photographic image manipulation, and
>>> DTP. For these uses, 64 bit is only about allowing larger memory
>>> address spaces per process, and the G5 lets you do that now.
>>
>> Hmm? From what I saw in Duane's comments, this isn't something that
>> MacOS-X supports, G5 or no. If they aren't supporting 64 bit pointers,
>> by default, then you have NOT got "larger memory address spaces per
>> process."
>
> I'm speculating here that Raffael's comment may imply that Apple has
> moved the kernel space above 4GB, permitting a full 4GB of address space
> for 32-bit applications, which could be an improvement of 1-2GB.
After some Googling this comment appears somewhat authoritative ;-)
<http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Architecture/chapter_3_section_1.html>
In Mac OS X, processes do not normally share memory. Instead, the
kernel assigns each process its own address space, controlling access
to these address spaces. This control ensures that no application can
inadvertently access or modify another application's memory
(protection). Size is not an issue; with the virtual memory system
included in Mac OS X, each application has access to its own 4 GB
address space.
This may gloss over the amount of RAM reserved for kernel processes.
Consider this comment: <http://www.macnn.com/news/20371&startNumber=20>
The OS can use ALL of the 8GB of RAM and will share it among all
processes running on the system. An individual application (process)
will only (currently) be able to address a virtual address space of 4GB
in size, just like on current G3/G4 systems (about 0.5 GB of that space
is consumed by kernel and shared memory mappings, so in general a
single process can get access to around 3.5 GB).
I think it's pretty safe to conclude that there will be no greater
effective address space for applications because of the introduction of
the 64-bit G5 processor given Apple's current operating system. In the
x86-32 world this is already handled using nasty Physical Address
Extension (PAE) hacks.
The bottom line is Apple needs to develop a 64-bit operating system.
Another thing I came across in my researching is that--unlike AMD64--there
may be no significant speed gains from migrating to a 64-bit platform. The
extra registers with x86-64 are only available when running in 64-bit mode
and being able to use them can lead to significant speed increases. So the
way AMD has implemented this gives people an incentive to migrate to
x86-64, even if they don't need the extra address space.
<http://www.aceshardware.com/forum?read=105026945>
"0" writes:
With AMD64, they have bundled 64-bit support with added GPRs and SSE
registers, so there will be a speed increase with a native AMD64 most
of the time. The media will not get this right. See what they say
about the G5 and 64-bit. PPC32 is a subset of PPC64, so there is no
extra registers exposed in 64-bit mode, which means, in general, no
performance improvement for 64-bit mode with the G5. It has just the
larger address space for the most part.
...
For most desktop uses, the main benefit of AMD64 will be more
registers, and not 64-bit itself. There are some advantages to running
32-bit applications under a 64-bit OS. Current 32-bit OSes only give
each process 2 to 3 GB of address space, while a 64-bit OS running a
32-bit application can give it almost the entire 4 GB. There are some
applications that can use the extra address space, but this will mostly
be for the workstation/server space at the moment with some exceptions.
[BTW this is the addressing advantage I speculated about in my first
reply]
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> For most desktop uses, the main benefit of AMD64 will be more
> registers, and not 64-bit itself.
Yes, this is true. Also, given more registers, their standard calling
convention includes passing arguments via registers - 6 in all, which
means that we can use a lisp calling abi more like the standard one
than we did in x86, where we actually forced our lisp abi to pass the
first two args in registers.
The decoding for what they call the REX prefix is kind of clever,
too, although it is a nightmare to decode by hand ...
CL-USER(5): (disassemble (compile (defun foo (x) (bar x))))
Warning: While compiling these undefined functions were referenced: BAR.
;; disassembly of #<Function FOO>
;; formals: X
;; constant vector:
0: BAR
;; code start: #x1000e901a8:
0: 55 pushq rbp
1: 48 8b ec movq rbp,rsp
4: 41 56 pushq r14
6: 48 83 ec 68 sub rsp,$104
10: 48 83 f8 01 cmp rax,$1
14: 74 01 jz 17
16: 06 (push es) ; SYS::TRAP-ARGERR
17: 41 80 7f a7 00 cmpb [r15-89],$0 ; SYS::C_INTERRUPT-PENDING
22: 74 01 jz 25
24: 17 (pop ss) ; SYS::TRAP-SIGNAL-HIT
25: 4d 8b 5e 36 movq r11,[r14+54] ; BAR
29: b0 01 movb al,$1
31: ff d3 call *rbx
33: c9 leave
34: 4c 8b 75 f8 movq r14,[rbp-8]
38: c3 ret
39: 90 nop
CL-USER(6):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> 16: 06 (push es) ; SYS::TRAP-ARGERR
I presume the parentheses mean the 64-bit mode doesn't support
the instruction, so the CPU raises an exception, which your Lisp
then uses for its own purposes.
And if the architecture is ever extended to reuse this opcode as
a prefix (as was done to POP CS already), then you'll release a
new version and ask customers to please recompile their programs.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > 16: 06 (push es) ; SYS::TRAP-ARGERR
>
> I presume the parentheses mean the 64-bit mode doesn't support
> the instruction, so the CPU raises an exception, which your Lisp
> then uses for its own purposes.
Yup.
> And if the architecture is ever extended to reuse this opcode as
> a prefix (as was done to POP CS already), then you'll release a
> new version and ask customers to please recompile their programs.
I think it's possible, but not too likely to happen. But even so,
it wasn't my first choice for interrupt simulations. I was forced
to use these because they were availiable for now and they worked.
The reason for this was because when I tried the `int n' instructions,
they didn't work. Andi Kleen of Suse was gracious enough to work
with me on this and found that the int instructions weren't getting
vectored properly, and were thus effectively being ignored. He fixed
it immediately in the Suse version. I think that it got into the
beta release for the version he was working on at the time, but it
will take some time to propagate these changes to all Linuxen.
The other interesting twist is that these illegal instructions
are one byte each, and the int instructions are two bytes each.
So I'm inclined to leave them in longer, rather than to necessarily
replace them right away in the next dot-release after this release
I'm working on.
And yet another twist is the unknown of what MS will do with their
AMD64 code; the x86 version has always ignored both illegal
instructions and int instructions (actually, it depends on the
origin of the kernel; the NT-based systems do better than the
win-95 based systems, but since we still support all of the
Win systems ...) so we use _software_ 'traps' (in the form of
calls, at three bytes per 'trap').
What will probably happen is that we'll release with the illegal
instructions as traps, but have the regular code and trap handlers
in for the int instructions. Then our dot-releases will make the
decision as to which approach to compile our own code with, and
users will probably be able to flip a switch for the code they want
to generate. Our trap handlers are general purpose, and we have
coded them at times to handle all three styles of interrupt handling:
trapping instructions, illegal instructions, and software traps.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> I think it's possible, but not too likely to happen. But even so,
> it wasn't my first choice for interrupt simulations. I was forced
> to use these because they were availiable for now and they worked.
[...]
That was interesting. Thank you for posting.
David Steuber <·············@verizon.net> writes:
[...]
> Companies that are criticized for having only a 3% market share
> should not be making such blunders. I am finding this more
> depressing by the minute.
I always wondered about this fascination about market share.
To be sure selling more is good (especially if you make a profit per
unit sold), but BMW, Mercedes and Jaguar all have small marketshares
and people don't mind that. Each company now of course is trying to
make their offerings more affordable, but if more people can afford
one then the cachet/brand image may suffer.
There's a "prestige"(?) to owning one of those cars since they're
expensive (and presumably of higher quality). Couldn't it be argued
that Apples are better designed/thought out and thus cost more,
therefore having a smaller market share?
Many people will be quite happy paying a little more for the
(perceived?) quality in those systems.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> wrote in message news:<··············@number6.magda.ca>...
> I always wondered about this fascination about market share.
>
> To be sure selling more is good (especially if you make a profit per
> unit sold), but BMW, Mercedes and Jaguar all have small marketshares
> and people don't mind that. Each company now of course is trying to
> make their offerings more affordable, but if more people can afford
> one then the cachet/brand image may suffer.
Network effects. The computing industry has them, cars don't. While
Apple has been pushing them away by embracing Unix/Java/MSOffice,
they've got a lot of dependencies that can hurt when things go bad.
Still, they've solved many problems. I'm curious how they'll deal
with DRM.
··········@yahoo.com (Tayss) wrote in message news:<····························@posting.google.com>...
> Network effects. The computing industry has them, cars don't. While
> Apple has been pushing them away by embracing Unix/Java/MSOffice,
> they've got a lot of dependencies that can hurt when things go bad.
The network effects of the computing industry are only relevant if you
don't interoperate with them. Apple does, ironically, more seamlessly
than Microsoft. For example, Office works *better* on Mac OS X than on
Windows. That annoying bug where you open a Word document and see
formatting code, not your document, I've never seen that with the Mac
version of Word.
Since these "network effects" are essentially irrelevant to Apple
users, Apple's market really is comparable to that of a luxury car
maker - people who will pay a premium for a product with better fit
and finish, that looks cooler.
·······@mediaone.net (Raffael Cavallaro) wrote...
> ··········@yahoo.com (Tayss) wrote...
> > Network effects. The computing industry has them, cars don't. While
> > Apple has been pushing them away by embracing Unix/Java/MSOffice,
> > they've got a lot of dependencies that can hurt when things go bad.
>
> The network effects of the computing industry are only relevant if you
> don't interoperate with them.
It's not often that someone agrees with me in such a disagreeing
manner. ;)
> Since these "network effects" are essentially irrelevant to Apple
> users, Apple's market really is comparable to that of a luxury car
> maker - people who will pay a premium for a product with better fit
> and finish, that looks cooler.
I know that's their market. My point is that avoiding the network
effects leads to dependencies. For example, right now MSOffice Pro
costs $500 at Apple.com. At Dell, they'll literally /pay you/ $30 if
you get it since it's their weekly special. Normally, I think you'd
pay $70 at Dell for it.
Further, if Apple attacked the PC market by dropping price, Microsoft
may make them suffer even more.
Another dependency is (I believe) on Samba for interop with Microsoft
fileshares. If MSFT intentionally played games with Samba's interop,
Apple would have a headache.
-- tayss_temp2 at the yahoo domain --
··········@yahoo.com (Tayss) wrote in message news:<····························@posting.google.com>...
> I know that's their market. My point is that avoiding the network
> effects leads to dependencies. For example, right now MSOffice Pro
> costs $500 at Apple.com. At Dell, they'll literally /pay you/ $30 if
> you get it since it's their weekly special. Normally, I think you'd
> pay $70 at Dell for it.
You don't *have* to go the Office route - interoperability with MS
file formats can be had without buying Office. This is why, for
example, Apple is including a .doc reader with the OS in the next rev
(Panther).
>
> Further, if Apple attacked the PC market by dropping price, Microsoft
> may make them suffer even more.
Once you can interoperate with their proprietary formats, they can
only make you suffer by cutting of their nose to spite their face.
I.e., they have to punish their own customers by making older versions
of their own software unable to read the newer file formats. This went
over like a lead balloon with the most recent .doc format change -
many fewer people upgraded than MS expected, and the older format has
become the de-facto standard.
>
> Another dependency is (I believe) on Samba for interop with Microsoft
> fileshares. If MSFT intentionally played games with Samba's interop,
> Apple would have a headache.
This would also hurt interoperability with the *nix world, so MS is
not as free to do this as one might think. MS, especially after the
antitrust ruling, is not in a position to demand that enterprises run
all Microsoft shops, from the server room to the desktop, in order to
interoperate. Ms would lose customers, as well as be in legal hot
water.
Remember, MS has already been legally established as a monopoly in
federal court. If MS tried to mess with Samba just to make *nix and
Mac OS break, we wouldn't have to wait for the DOJs antitrust unit -
Apple, Sun, and others would sue them for antitrust violations.
a) When you argue that Apple is attempting to make itself immune to
network affects, we are in full agreement.
b) When you claim Microsoft can't necessarily enforce network effects,
we are also in agreement. There is a difference between what MSFT
would do in its ideal world, and what it can accomplish in the real
one. It's not a game where MSFT makes all the moves.
c) If however your position is that network effects can be ignored in
the PC industry, we'll have to agree to disagree. Dunno what to say
to that, we'd just be disagreeing on such a fundamental level...
-- tayss_temp2 at the yahoo domain --
··········@yahoo.com (Tayss) wrote in message news:<····························@posting.google.com>...
> b) When you claim Microsoft can't necessarily enforce network effects,
> we are also in agreement. There is a difference between what MSFT
> would do in its ideal world, and what it can accomplish in the real
> one. It's not a game where MSFT makes all the moves.
No, we are not in agreement here, because you wrote:
"they've got a lot of dependencies that can hurt when things go bad."
Your statement is only true if MSFT can enforce network effects that
benefit MSFT. My point is that Apple's network dependencies are fewer
than you represent, and less enforceable by MSFT than they were 5
years ago.
> c) If however your position is that network effects can be ignored in
> the PC industry
It's not. My position is that Apple is much more immune to MSFT
specific network effects than Apple was in the recent past. Moreover,
learning to live in the shadow of a rogue MSFT has taught Apple how to
work around network effects and achieve even *better* interoperability
than MSFT has.
·······@mediaone.net (Raffael Cavallaro) wrote:
> No, we are not in agreement here, because you wrote:
> "they've got a lot of dependencies that can hurt when things go bad."
> Your statement is only true if MSFT can enforce network effects that
> benefit MSFT. My point is that Apple's network dependencies are fewer
> than you represent, and less enforceable by MSFT than they were 5
> years ago.
I don't only assume MSFT has network effects. Unix and the Java
platform have them. Apple has moved to minimize these effects. But
porting even a Java program takes a bit of effort that could be better
allocated elsewhere for two versions, especially if the app is impure
or you hit an odd bug. I use unix often, but rarely install/admin it;
yet I suspect it is still painful to move a GUI program from Linux to
Darwin.
Also there are defacto network effects on the Windows platform. No
Kazaa -- which is a killer app. Apple's answer is basically iTunes.
Perhaps something like Neo /might/ interop, but you're depending on
the goodwill of a company with incentives to break compatibility with
parasitic software. (They recently invoked the DMCA against the
"parasitic" Kazaa Lite's Google listings.)
Developers have every reason to question whether Apple's 3%
marketshare is worth catering to. Perhaps that 3% is more price
insensitive, but then again they paid a lot of their cash for their
Macs + Office.
Jobs claimed recently that while more marketshare would be nice, it
would be a mistake to move for it quickly and lose profit.
http://www.macdailynews.com/comments.php?id=P1813_0_1_0
It links to an Independent.co.uk interview/analysis, which now costs
money.
Further, their actions against loyal companies is another factor of
that calculation developers must make:
* Karelia (whose utility they clearly ripped off)
* Adobe (Apple competes with video editing software)
* Omnigroup (Safari competes with its browser)
Since Apple is still executing on its strategies, they are perceived
as more likely to compete against its developers, relative to the size
of their 3rd party base.
Also, Microsoft bought Connectix, which was long considered the
likeliest chance to interop with Windows.
Still, I believe we're agreeing violently. My main disagreement is
your perception we disagree.
> It's not. My position is that Apple is much more immune to MSFT
> specific network effects than Apple was in the recent past. Moreover,
> learning to live in the shadow of a rogue MSFT has taught Apple how to
> work around network effects and achieve even *better* interoperability
> than MSFT has.
"Much more immune." "Work around network effects and achieve *better*
interoperability." You say these sentences; you claim there are no
network effects but then you say these things that explicitly assume
the existence of network effects that Apple struggles against.
In fact, it is a non sequitur to say that Apple is achieving better
interop than Microsoft. We have been assuming that Microsoft's enemy
is interop, and your statement is inconsistent with that. It is
dangerous for Apple software not to reproduce bugs.
Further, you probably assume the US judicial system has more power
than it does. Roosevelt had power to pimpslap the Supreme Court when
they acted against his New Deal. While he spent political capital to
do it, the Supremes would have been destroyed had they remained
stubborn. Further, on the case where automotive companies like GM
bought up the efficient US light rail after WWII and wrecked them to
force demand of automobiles/busses, the courts fined them $500, and
each executive $1. Guilt is irrelevant if it is not enforced.
I've been in an argumentative mood for the last few days. Best to end
it now and get back to important things... After all, I can throw a
rock in Silicon Valley and hit a company that's more vindictive,
cattier and less successful than MSFT. Gabriel covers some of this in
_Patterns of Software_. So there's probably little point to arguments
where both sides implicitly assume Microsoft is some boogieman.
··········@yahoo.com (Tayss) wrote in message news:<····························@posting.google.com>...
> ·······@mediaone.net (Raffael Cavallaro) wrote:
> > No, we are not in agreement here, because you wrote:
> > "they've got a lot of dependencies that can hurt when things go bad."
> > Your statement is only true if MSFT can enforce network effects that
> > benefit MSFT. My point is that Apple's network dependencies are fewer
> > than you represent, and less enforceable by MSFT than they were 5
> > years ago.
>
> I don't only assume MSFT has network effects. Unix and the Java
> platform have them.
Well they must be a non-issue for Apple, 'cause Gosling himself uses
Mac OS X for his Java work.
> Apple has moved to minimize these effects.
So there are not "a lot of dependencies that can hurt when things go
bad."
> Developers have every reason to question whether Apple's 3%
> market share is worth catering to.
To put it bluntly, who cares? Every developer who abandoned Apple 5
years ago because their piddling 3% market share wasn't enough, is now
running to play catch up with those who didn't jump ship. Apple's 3%
is not like 3% of the PC software market. It represents a
disproportionate share of software sales (note, not software *use*,
but paid sales) because it automatically filters out the cheapo
market. People who will pay the premium for a Mac system, will *buy*
not "borrow" software. Recent events have shown that if this market
segment is too small and unimportant for one developer, then another
developer will gladly fill their place.
> Further, you probably assume the US judicial system has more power
> than it does.
That's the beauty of a finding of criminal wrong doing - it is
dispositive in civil court. In other words, when suing MS in civil
court, one doesn't have to prove that they have acted illegally as a
monopoly. You just point at the finding of fact, and the court just
says, "yup, they are."
So, no, I'm making no assumptions about the power of the judicial
system. I'm only assuming that parties who are wronged by MSFT will
take slam dunk action against them if and when MSFT violates the terms
of its settlement, or antitrust law in general. The DOJ can be
completely in MSFT's pocket, but that can't stop Apple, or other
injured parties, from having injunctions issued against MSFT if they
step over the line. The existing findings mean that matters will be
litigated by the interested parties. We don't need to rely on the good
faith of the DOJ anymore. MSFT knows this, which is why their behavior
has changed. They know that they came damned close to being split up,
and that Kollar-Kotelly will revisit penalties against MSFT if they
misbehave again, whether or not the DOJ is on board.
> I've been in an argumentative mood for the last few days.
I haven't exactly been pouring oil on troubled waters in this exchange
either. As you say, little point in our continuing to agree so
violently.
regards,
Raf
··········@yahoo.com (Tayss) wrote in message news:<····························@posting.google.com>...
> ·······@mediaone.net (Raffael Cavallaro) wrote:
> > No, we are not in agreement here, because you wrote:
> > "they've got a lot of dependencies that can hurt when things go bad."
> > Your statement is only true if MSFT can enforce network effects that
> > benefit MSFT. My point is that Apple's network dependencies are fewer
> > than you represent, and less enforceable by MSFT than they were 5
> > years ago.
>
> I don't only assume MSFT has network effects. Unix and the Java
> platform have them.
Well they must be a non-issue for Apple, 'cause Gosling himself uses
Mac OS X for his Java work.
> Apple has moved to minimize these effects.
So there are not "a lot of dependencies that can hurt when things go
bad."
> Developers have every reason to question whether Apple's 3%
> market share is worth catering to.
To put it bluntly, who cares? Every developer who abandoned Apple 5
years ago because their piddling 3% market share wasn't enough, is now
running to play catch up with those who didn't jump ship. Apple's 3%
is not like 3% of the PC software market. It represents a
disproportionate share of software sales (note, not software *use*,
but paid sales) because it automatically filters out the cheapo
market. People who will pay the premium for a Mac system, will *buy*
not "borrow" software. Recent events have shown that if this market
segment is too small and unimportant for one developer, then another
developer will gladly fill their place.
> Further, you probably assume the US judicial system has more power
> than it does.
That's the beauty of a finding of criminal wrong doing - it is
dispositive in civil court. In other words, when suing MS in civil
court, one doesn't have to prove that they have acted illegally as a
monopoly. You just point at the finding of fact, and the court just
says, "yup, they are."
So, no, I'm making no assumptions about the power of the judicial
system. I'm only assuming that parties who are wronged by MSFT will
take slam dunk action against them if and when MSFT violates the terms
of its settlement, or antitrust law in general. The DOJ can be
completely in MSFT's pocket, but that can't stop Apple, or other
injured parties, from having injunctions issued against MSFT if they
step over the line. The existing findings mean that matters will be
litigated by the interested parties. We don't need to rely on the good
faith of the DOJ anymore. MSFT knows this, which is why their behavior
has changed. They know that they came damned close to being split up,
and that Kollar-Kotelly will revisit penalties against MSFT if they
misbehave again, whether or not the DOJ is on board.
> I've been in an argumentative mood for the last few days.
I haven't exactly been pouring oil on troubled waters in this exchange
either. As you say, little point in our continuing to agree so
violently.
regards,
Raf
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> Also there are defacto network effects on the Windows platform. No
> Kazaa -- which is a killer app. Apple's answer is basically iTunes.
I haven't tried it, but I believe there is a Mac client for Kazaa.
> Developers have every reason to question whether Apple's 3%
> marketshare is worth catering to. Perhaps that 3% is more price
> insensitive, but then again they paid a lot of their cash for their
> Macs + Office.
There is also the question: "3% of *what*?". Lots more Windows machines
are being sold than Macs, but the vast majority are probably going into
offices, where they will never again take part in the software market --
they get Office or some vertical market app on them and then nothing
more.
I think we'll see an excellent example of this when the Windows version
of the iTunes Music Store opens. Windows users will probably buy more
than Mac users, but *not* twenty times more. Even all the different
Windows-compatable music stores put together won't sell twenty times
more than the Mac version of the iTunes Music Store. I fact I'm picking
they'll struggle to total better than five times more.
Note also that Apple is now up to something like 9% of current sales in
the laptop computer market.
> Further, their actions against loyal companies is another factor of
> that calculation developers must make:
> * Karelia (whose utility they clearly ripped off)
You're going to have a *really* hard job to convince people that being a
Windows developer is any safer!
> * Adobe (Apple competes with video editing software)
Adobe isn't loyal to anyone but Adobe (and nor should they be). Look at
their recent (pre G5) ads saying that Photoshop is better on Windows.
And their video editing software was/is crap.
> * Omnigroup (Safari competes with its browser)
They're switching to *using* the Safari rendering engine, with their own
interface.
I could be wrong, but I think Apple would *prefer* to have strong apps
from 3rd parties, but if they want to see something good in some niche
and no one is filling that niche, or they are filling it with crap, then
Apple are prepared to roll up their sleeves and do it themselves.
-- Bruce
Bruce Hoult <·····@hoult.org> wrote:
> They're switching to *using* the Safari rendering engine, with their own
> interface.
I read Omnigroup's press release too. You might be interested in
Holden & Nagle's book on pricing; they illustrate how companies
irrationally regard losing sunk costs. While you and I might think
this is an opportunity to reduce costs and ride a brand...
> You're going to have a *really* hard job to convince people that being a
> Windows developer is any safer!
Either Kernighan or Ritchie (never get those two straight...) recently
praised Microsoft for providing a platform that gave good livings to
programmers inside and out of Redmond. Whatever the pain of competing
in the IT world is, MSFT has been relatively benign. People do not
realize what an insanely cutthroat industry this is, and attribute it
to the current top company. Charles Ferguson's _High Stakes, No
Prisoners_ has a nuanced view on this.
Ray Ozzie (of Groove and Lotus Notes) blogged about how investors walk
away from platforms where there is no conflict with 3rd party
developers. The question is of balance.
Apple is still defining their platform.
> I think we'll see an excellent example of this when the Windows version
> of the iTunes Music Store opens. Windows users will probably buy more
> than Mac users, but *not* twenty times more.
Probably. Ultimately it's up to Apple to make iTunes attractive to
Windows users. I've always gotten the impression from Jobs' keynotes
that Apple is halfhearted when it comes to Windows ports.
Especially since Windows people have access to 69 cent songs, IIRC.
But whatever. I like receiving Apple Developer Connection CDs in the
mail as much as the next person. I recommend Macs early & often, but
I think there's a way to like Macs without people expecting me to give
Steve a full blowjob. A boy can dream, can't he?
··········@yahoo.com (Tayss) writes:
> Especially since Windows people have access to 69 cent songs, IIRC.
Isn't that the rapper who keeps getting shot? Not much variety there.
> But whatever. I like receiving Apple Developer Connection CDs in the
> mail as much as the next person. I recommend Macs early & often, but
> I think there's a way to like Macs without people expecting me to give
> Steve a full blowjob. A boy can dream, can't he?
I downloaded the ADC software for my 12" PowerBook G4. I am rather
disappointed that it is not included in the Software Updates feature
so that I can update to the latest version like I can with Debian
Linux.
I've heard that Steve likes rim jobs as well. It would certainly
explain a lot. Probably a subject for alt.tasteless.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> One Emacs to rule them all. One Emacs to find them,
> One Emacs to bring them all and in the darkness bind them.
Actually...
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
In the land of Stallman, where free software lies.
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@verizon.net>,
> David Steuber <·············@verizon.net> wrote:
>
> > One Emacs to rule them all. One Emacs to find them,
> > One Emacs to bring them all and in the darkness bind them.
>
> Actually...
> One Emacs to rule them all. One Emacs to find them,
> One Emacs to take commands and to the keystrokes bind them,
> In the land of Stallman, where free software lies.
That is good. I may well consider stealing that.
What I would like would be to do an Emacsian version of the entire
poem:
Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie,
One Ring to rule them all. One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
Sadly, I have not the tallent to come up with such a poem yet.
But I am working on it.
* I do hope I'm not violating the DMCA by posting the poem in full.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> > Actually...
> > One Emacs to rule them all. One Emacs to find them,
> > One Emacs to take commands and to the keystrokes bind them,
> > In the land of Stallman, where free software lies.
>
> That is good. I may well consider stealing that.
>
> What I would like would be to do an Emacsian version of the entire
> poem:
>
> Three Rings for the Elven-kings under the sky,
> Seven for the Dwarf-lords in their halls of stone,
> Nine for Mortal Men doomed to die,
> One for the Dark Lord on his dark throne
> In the Land of Mordor where the Shadows lie,
> One Ring to rule them all. One Ring to find them,
> One Ring to bring them all and in the darkness bind them
> In the Land of Mordor where the Shadows lie.
Knuth's Tex for the Math-kings of sigma, and pi,
Unix vim for the Server-lords with their O'Reilly tomes,
Word for Mortal Men doomed to die,
Emacs from the Bearded One on his Gnu throne,
In the land of Stallman where free software lies.
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
In the land of Stallman, where free software lies.
Raf
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> David Steuber <·············@verizon.net> wrote:
>
> > What I would like would be to do an Emacsian version of the entire
> > poem:
> >
> > Three Rings for the Elven-kings under the sky,
> > Seven for the Dwarf-lords in their halls of stone,
> > Nine for Mortal Men doomed to die,
> > One for the Dark Lord on his dark throne
> > In the Land of Mordor where the Shadows lie,
> > One Ring to rule them all. One Ring to find them,
> > One Ring to bring them all and in the darkness bind them
> > In the Land of Mordor where the Shadows lie.
>
> Knuth's Tex for the Math-kings of sigma, and pi,
> Unix vim for the Server-lords with their O'Reilly tomes,
> Word for Mortal Men doomed to die,
> Emacs from the Bearded One on his Gnu throne,
> In the land of Stallman where free software lies.
> One Emacs to rule them all. One Emacs to find them,
> One Emacs to take commands and to the keystrokes bind them,
> In the land of Stallman, where free software lies.
OK, consider this stolen. Is this yours? If not, who do I credit?
Next step for my sig file will be the entire contents of /dev/random.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> OK, consider this stolen. Is this yours? If not, who do I credit?
Yes, I wrote it. Feel free to use it. I hold the copyright of course,
but I hereby publish this work under the Creative Commons
Attribution-NonCommercial-ShareAlike 1.0 License (reccommended by the
Free Software Foundation - appropriate given the subject of the poem,
don't you think?)
The Lord of the Editors
or
One Emacs to Rule Them All
by Raffael Cavallaro
Knuth's Tex for the Math-kings of sigma, and pi,
Unix vim for the Server-lords with their O'Reilly tomes,
Word for Mortal Men doomed to die,
Emacs from the Bearded One on his Gnu throne,
In the land of Stallman where free software lies.
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
In the land of Stallman, where free software lies.
copyright 2003 Raffael Cavallaro, All Rights Reserved
published under the Creative Commons
Attribution-NonCommercial-ShareAlike 1.0 License
You are free:
to copy, distribute, display, and perform the work
to make derivative works
Under the following conditions:
Attribution . You must give the original author credit.
Noncommercial . You may not use this work for commercial purposes.
Share Alike . If you alter, transform, or build upon this work, you may
distribute the resulting work only under a license identical to this
one.
For any reuse or distribution, you must make clear to others the license
terms of this work.
Any of these conditions can be waived if you get permission from the
author.
Your fair use and other rights are in no way affected by the above.
This is a human-readable summary of the Legal Code .
(see <http://creativecommons.org/licenses/by-nc-sa/1.0/legalcode> for
the full text of the license)
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> Yes, I wrote it. Feel free to use it. I hold the copyright of course,
> but I hereby publish this work under the Creative Commons
> Attribution-NonCommercial-ShareAlike 1.0 License (reccommended by the
> Free Software Foundation - appropriate given the subject of the poem,
> don't you think?)
Yes, indeed.
All terms and conditions trimmed from previous post are preserved in
Google archive.
Now to add the entire contents of /dev/random to the end of the sig
<EG>
--
Knuth's Tex for the Math-kings of sigma, and pi,
Unix vim for the Server-lords with their O'Reilly tomes,
Word for Mortal Men doomed to die,
Emacs from the Bearded One on his Gnu throne,
In the land of Stallman where free software lies.
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
In the land of Stallman, where free software lies.
--- Raffael Cavallaro
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> Network effects. The computing industry has them, cars don't. While
They do. For example, people don't like to buy a car that they have to
drive several hours to another city to get serviced. I know this
affects manufacturers as large as Fuji Heavy Industries, who seem to
sell significant numbers of cars only in pockets of the USA such as
Colarado and Washington and New England.
-- Bruce
··········@yahoo.com (Tayss) writes:
> Network effects. The computing industry has them, cars don't. While
> Apple has been pushing them away by embracing Unix/Java/MSOffice,
> they've got a lot of dependencies that can hurt when things go bad.
Embracing MSOffice? My Mac came with a test drive. The product costs
another $320. Fug that.
Speaking of Office, does anyone have some good VBA code that I can
embed in a doc format version of my resume to delete all other resumes
from a perspective employer's computer system and network?
Nah, that's not even a little bit off topic ;-)
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Magda wrote:
> To be sure selling more is good (especially if you make a profit per
> unit sold), but BMW, Mercedes and Jaguar all have small marketshares
> and people don't mind that. Each company now of course is trying to
> make their offerings more affordable, but if more people can afford
> one then the cachet/brand image may suffer.
>
> There's a "prestige"(?) to owning one of those cars since they're
> expensive (and presumably of higher quality). Couldn't it be argued
> that Apples are better designed/thought out and thus cost more,
> therefore having a smaller market share?
The problem is there is little prestige to owning a computer, and
apple hasn't managed to play well to it. There is prestige, of a
sort, in being able to demonstrate mastery of computers, but it's
largely limited to people who actually program. And people who
actually program tend to prefer either the linux platform for its
deep configurability, visible source code, and plethora of free
development tools, or the windows platform for its market share.
OS X goes a long way to address this problem, but it doesn't do
as well as Linux.
There is prestige, of a sort, in having the latest and greatest most
powerful hardware in the world, and churning out massive renders or
huge compiles or ····@home workloads -- But the makers of chips that
have the Pentium III+ instruction set have a massive market share
that allows them to amortize plant costs over a much bigger number
of units and the raw-CPU-power per money ratio is therefore higher
on the intel (and clone) hardware.
There is prestige, of a sort, in being able to get the absolute
most possible useful work out of your hardware no matter how
limited the hardware may be. This is where linux really shines
and where apple has historically been deficient. If you want
to use a machine as a fileserver, there's no need to support
the overhead of a GUI. If you want to use a machine as a
netbooted firewall or router, there's no need to have hard
disk drivers or keyboard drivers or video drivers installed.
The makers of embedded systems just love this; not every
machine has to be a desktop workstation. Linux does this, in
fact, so well that nobody could possibly make any money trying
to imitate them.
There is a valid perception of quality in having software that
doesn't crash all the time. Historically, apple did this a lot
better than windows. Windows is playing catch-up with their
latest offerings. But I've got Linux boxes I use hard, and do
lots of compiles and software testing on, that have six month
uptimes. I'm not holding my breath for any commercial OS to
routinely hit marks like that.
There is a valid perception of quality in having an OS that
keeps private information private and repels vandals, theives,
and crackers. Windows is in the toilet on this one. Linux
and Apple both do it reasonably well. Which is better in this
department depends on who's configuring the linux system.
What Apple has spent twenty years selling is the computer for
people who don't want to have to care about how their computer
works and don't want to have to know enough to configure it
optimally or secure it themselves. That's a valid market
segment, and it's a big group of people who have a legitimate
need for computers, and apple has historically done a good
job of addressing their needs - but "prestige" is probably
not the right word to use to describe it.
Bear
Ray Dillinger <····@sonic.net> writes:
> David Magda wrote:
>
>
> > To be sure selling more is good (especially if you make a profit per
> > unit sold), but BMW, Mercedes and Jaguar all have small marketshares
> > and people don't mind that. Each company now of course is trying to
> > make their offerings more affordable, but if more people can afford
> > one then the cachet/brand image may suffer.
> >
> > There's a "prestige"(?) to owning one of those cars since they're
> > expensive (and presumably of higher quality). Couldn't it be argued
> > that Apples are better designed/thought out and thus cost more,
> > therefore having a smaller market share?
I think Apple is going for something more like the BMW, Jag, Alpha,
and nowadays VW and Cadillac, market; quality and chic. I get an
average of 5-10 people per month asking me about my iBook, partly
because it just looks so nice. Oh, and compare their prices to Dell
-- Apples aren't expensive; they're a little more, but not much (and
sometimes less).
> The problem is there is little prestige to owning a computer, and
> apple hasn't managed to play well to it.
I think you were cutting this the wrong way; given that people want
computers, now what? Well, stylishly minded people want stylish
computers. Certainly there are style-free Apple owners, but in
general, if someone buys designer paints/clothes/car-chrome/etc, odds
are a lot better that they own a Mac than a PC.
> What Apple has spent twenty years selling is the computer for
> people who don't want to have to care about how their computer
> works and don't want to have to know enough to configure it
> optimally or secure it themselves. That's a valid market
> segment, and it's a big group of people who have a legitimate
> need for computers, and apple has historically done a good
> job of addressing their needs - but "prestige" is probably
> not the right word to use to describe it.
You're seriously underestimating their approach of the last few years.
When you buy an Apple, you get everything you need, easy-to-use,
properly configured, and just ... nice. I know that MS spends more on
usability testing, but they must have drunk chimps interpreting the
results. The already-configured, easy-to-use approach with OS X
applies to a lot more users than it used to; me, for example. Sure, I
can configure and lock down a Linux or Solaris box, but I don't want
to, I'm a programmer, not a sysadmin. I do want to have the ability
to configure things, though, and I have that too (hey, cool, there's
the Apache config file).
Between all the cringe-inducingly-named iLife apps, AppleWorks, and
the DevelTools, I have a fantastic environment. Sure, I instantly
installed a graphical Emacs, Lisp, and TeX, but that's about all that
was immediately missing.
I strongly suspect that their US market is concentrated in SF, LA, and
NYC, and not Chicago or Atlanta. I have no idea, but I'd suspect that
Rome and Milano also have a higher concentration of Mac users than
most of Europe.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> I have no idea, but I'd suspect that
> Rome and Milano also have a higher concentration of Mac users than
> most of Europe.
Don't forget Paris ;^)
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> You're seriously underestimating their approach of the last few years.
> When you buy an Apple, you get everything you need, easy-to-use,
> properly configured, and just ... nice. I know that MS spends more on
> usability testing, but they must have drunk chimps interpreting the
> results. The already-configured, easy-to-use approach with OS X
> applies to a lot more users than it used to; me, for example. Sure, I
> can configure and lock down a Linux or Solaris box, but I don't want
> to, I'm a programmer, not a sysadmin. I do want to have the ability
> to configure things, though, and I have that too (hey, cool, there's
> the Apache config file).
I had been pining for a Mac for quite some time before I finally got
my 12" PowerBook G4. I had certain criteria that I wanted to meet,
and the PowerBook did it for me. And that 'just works' thing was
quite different from my prior experience with Linux and that other
operating system from Redmond.
It took me a while though to put a graphical Emacs on my Mac. I was
using Apple X11 and ssh'ing into my Debian box. Actually, I am still
doing that right this very second.
However, the more powerful Debian box is in serious jeopardy. I still
have a strong Linux mind set about how things should be set up. I
found out last night that my PowerBook does have sendmail but I still
want to compile and install exim. More time consuming, yes. But I am
learning some useless trivia about email. When e-mail and Usenet is
finally moved over to my PowerBook, the Debian box will be powered
down until I need the raw horse power that it gives me. If I ever get
an iPod, I will probably use my Debian box to get all my CDs converted
over to MP3. I prefer LAME.
The little keyboard one the PowerBook works very well for me. I don't
mind the tiny screen. I can use this computer from wherever. I hate
being tied to a desk.
All that said, I do wish that Apple didn't go all 64 bit in their
marketing for the G5. The hardware may be all that, but without the
proper OS support and compiler support, it's gonna be loafing along in
G4 emulation mode. I would really like 64 bit memory mapped files.
I also keep noticing that Linux seems to have better memory management
than OS X 10.2.6. My old PII 233Mhz laptop with 128Mb or RAM still
seems to do things in a snappier fashion. The PowerBook weighs about
half as much though.
Whatever Apple's demographic is, I seem to be one of the statistical
aberrations. I am treating my Mac as a Unix box with pretty GUI.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
David Steuber <·············@verizon.net> writes:
[...]
> It took me a while though to put a graphical Emacs on my Mac. I
> was using Apple X11 and ssh'ing into my Debian box. Actually, I am
> still doing that right this very second.
http://members.shaw.ca/akochoi-emacs/
When GNU Emacs 21.4 is released. compiling on OS X should be possible
straight from the source.
More at: http://www.porkrind.org/emacs/
I don't know about XEmacs.
[...]
> I also keep noticing that Linux seems to have better memory
> management than OS X 10.2.6. My old PII 233Mhz laptop with 128Mb
> or RAM still seems to do things in a snappier fashion. The
> PowerBook weighs about half as much though.
[...]
How much does the Aqua GUI take up?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> David Steuber <·············@verizon.net> writes:
> [...]
> > It took me a while though to put a graphical Emacs on my Mac. I
> > was using Apple X11 and ssh'ing into my Debian box. Actually, I am
> > still doing that right this very second.
>
> http://members.shaw.ca/akochoi-emacs/
>
> When GNU Emacs 21.4 is released. compiling on OS X should be possible
> straight from the source.
I've got the CVS version 21.3.50 built and running. I'm using GNUS
and Mutt on my Debian box. Emacs builds fine for OS X using Carbon.
> How much does the Aqua GUI take up?
Not sure exactly. Here are a few lines from the ps command:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
david 488 0.0 0.1 49344 872 ?? S Wed07PM 0:01.61 quartz-wm
david 489 0.0 0.1 4348 868 ?? S Wed07PM 0:20.32 xterm
david 16774 0.0 0.1 2100 832 p2 S+ 12:54PM 0:39.71 ssh -X vega
And from top:
Processes: 46 total, 2 running, 44 sleeping... 128 threads 22:50:11
Load Avg: 0.69, 0.35, 0.15 CPU usage: 11.8% user, 12.7% sys, 75.5% idl
SharedLibs: num = 7, resident = 2.06M code, 136K data, 556K LinkEdit
MemRegions: num = 5312, resident = 231M + 5.57M private, 70.0M shared
PhysMem: 65.1M wired, 221M active, 134M inactive, 421M used, 219M free
VM: 2.16G + 3.62M 32052(0) pageins, 60051(0) pageouts
There is no free :-/
X11 is not included in whatever memory is used by quarts-wm. Those
commands get cut off.
Did we take three left turns some place?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber <·············@verizon.net> writes:
> It took me a while though to put a graphical Emacs on my Mac. I was
> using Apple X11 and ssh'ing into my Debian box. Actually, I am still
> doing that right this very second.
I didn't say what kind of graphical Emacs I was using ;-)
(I do have a Carbon build, but I mostly use the X11 one)
> However, the more powerful Debian box is in serious jeopardy. I still
> have a strong Linux mind set about how things should be set up. I
> found out last night that my PowerBook does have sendmail but I still
> want to compile and install exim. More time consuming, yes. But I am
> learning some useless trivia about email. When e-mail and Usenet is
> finally moved over to my PowerBook, the Debian box will be powered
> down until I need the raw horse power that it gives me. If I ever get
> an iPod, I will probably use my Debian box to get all my CDs converted
> over to MP3. I prefer LAME.
I'm a convert to iTunes -- I actually stopped using Emacs to manage my
mp3s. The kicker was being able to rip to AAC (m4a). I mostly listen
to R&B, and despite living in Cali, the hip-hop I listen to is mostly
east-coast. The difference (at least for my music) between
high-quality mp3s and m4as is amazing -- I can actually bear to hear a
high-hat driven track.
> I also keep noticing that Linux seems to have better memory management
> than OS X 10.2.6. My old PII 233Mhz laptop with 128Mb or RAM still
> seems to do things in a snappier fashion. The PowerBook weighs about
> half as much though.
I don't think it has a bad VM system, it's just a memory pig. If you
put enough RAM in, it's snappy; and you *can* use that memory for big
computations, because at least the huge processes sit still if you're
not poking at them.
> Whatever Apple's demographic is, I seem to be one of the statistical
> aberrations. I am treating my Mac as a Unix box with pretty GUI.
Actually, we're both part of that market, and they're going after us
intentionally. I'll give you one guess who they made X11.app for :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> David Steuber <·············@verizon.net> writes:
>
> > It took me a while though to put a graphical Emacs on my Mac. I was
> > using Apple X11 and ssh'ing into my Debian box. Actually, I am still
> > doing that right this very second.
>
> I didn't say what kind of graphical Emacs I was using ;-)
> (I do have a Carbon build, but I mostly use the X11 one)
This is my first Usenet posting using Carbon Emacs21 on OS X :-). I
am now wondering what would happen if I compile with both Carbon and
X11 support. How would Emacs start up?
I still have to sort out how to use Gnus for e-mail.
> > down until I need the raw horse power that it gives me. If I ever get
> > an iPod, I will probably use my Debian box to get all my CDs converted
> > over to MP3. I prefer LAME.
Write after I sent this, it occurred to me that I could probably get
LAME or build LAME on my PowerBook. There is nothing UI dependent in
the code.
> I'm a convert to iTunes -- I actually stopped using Emacs to manage my
> mp3s. The kicker was being able to rip to AAC (m4a). I mostly listen
> to R&B, and despite living in Cali, the hip-hop I listen to is mostly
> east-coast. The difference (at least for my music) between
> high-quality mp3s and m4as is amazing -- I can actually bear to hear a
> high-hat driven track.
I've heard mixed reviews about the AAC codec. I can't imagine
128kbps being adequate. I'm surprised the 364kbps stream used on DVD
sounds so good though. Hmmm.
> > I also keep noticing that Linux seems to have better memory management
> > than OS X 10.2.6. My old PII 233Mhz laptop with 128Mb or RAM still
> > seems to do things in a snappier fashion. The PowerBook weighs about
> > half as much though.
>
> I don't think it has a bad VM system, it's just a memory pig. If you
> put enough RAM in, it's snappy; and you *can* use that memory for big
> computations, because at least the huge processes sit still if you're
> not poking at them.
I don't know. I've got 640MB in the PowerBook. It must be one
serious pig!
> > Whatever Apple's demographic is, I seem to be one of the statistical
> > aberrations. I am treating my Mac as a Unix box with pretty GUI.
>
> Actually, we're both part of that market, and they're going after us
> intentionally. I'll give you one guess who they made X11.app for :-)
Fred, who lives around the corner?
I heard a rumor that Panther was going to at least bundle X11 in
rather than make it a separate download and perhaps even have better
X11 integration. That would be nice.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Magda <··················@ee.ryerson.ca> writes:
> David Steuber <·············@verizon.net> writes:
> [...]
> > Companies that are criticized for having only a 3% market share
> > should not be making such blunders. I am finding this more
> > depressing by the minute.
>
> I always wondered about this fascination about market share.
For computers there's a network type effect. For normal widgets, the
demand curve goes down as you pentrate the market. For "standards"
(defacto as well as dejure) like computer file formats, utility
actually _increases_ the more people use them. E.g., MS-word is
really valuable because that's what everyone else is using and they
send you things in that format and expect (requre in the case of the
US DoD) things in that format too.
For computer languages, the fact that many people are using C++, perl
and python means that those languages get good support in the OS, that
many good libraries exist and many people know how to use them. Thus
market share winners keep winning. Worse is better &c.
> To be sure selling more is good (especially if you make a profit per
> unit sold), but BMW, Mercedes and Jaguar all have small marketshares
> and people don't mind that. Each company now of course is trying to
> make their offerings more affordable, but if more people can afford
> one then the cachet/brand image may suffer.
I like using TeX and Lisp. Compared to ms-word and C++ they have
small marketshares. I wish they were larger since using them is an
uphill battle when I need to deal with my cow-orkers.
> There's a "prestige"(?) to owning one of those cars since they're
> expensive (and presumably of higher quality). Couldn't it be argued
> that Apples are better designed/thought out and thus cost more,
> therefore having a smaller market share?
Well, sure. But fancy cars will operate on regular roads and use
petrol like simpler cars. Try to use a presige coal fired steam
carriage too wide to fit in a lane. No one can have a car for which
they need to supply their own infrastructure.
> Many people will be quite happy paying a little more for the
> (perceived?) quality in those systems.
Sure. I hope that Apple succeeds in growing market. Too much
monoculture is a bad thing.
--
Johan KULLSTAM <··········@comcast.net> sysengr
Johan Kullstam <··········@comcast.net> writes:
> I like using TeX and Lisp. Compared to ms-word and C++ they have
> small marketshares. I wish they were larger since using them is an
> uphill battle when I need to deal with my cow-orkers.
I do hope that was *not* a typo.
It annoys me to no end when people want a resume in doc rather than
pdf. See my other post. I want to please them <eg>
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Magda <··················@ee.ryerson.ca> writes:
> To be sure selling more is good (especially if you make a profit per
> unit sold), but BMW, Mercedes and Jaguar all have small marketshares
> and people don't mind that. Each company now of course is trying to
> make their offerings more affordable, but if more people can afford
> one then the cachet/brand image may suffer.
Of course Jaguar is no longer an independent company, and both Mercedes
and (to a lesser extent) BMW have acquired other automobile
manufacturers to grow the size of their business.
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> > > Heh, heh. Even before I tried this I could tell that this was
> > > marketing slime from Apple to hide the fact that they truly don't
> > > have 64-bits yet. In a 64-bit port, a long is a 64-bit value
> >
> > There are perfectly good reasons for not doing that, such as source code
> > compatability with legacy (aka "broken") code that expects particular
> > sizes. I'm sure there is a *lot* of that out there.
>
> No, all 64-bit operating systems have the same size longs. It is
> because longs are defined to be the same size as a pointer.
OK, good point, that *is* in the C standard, so it probably needs to be
at least an available compiler option for programs that use more than 4
GB.
> > Are the 64 bit *instructions* there in the CPU or not? Are the
> > registers 64 bit or not?
>
> Absolutely. What does that have to do with a 64-bit _system_?
> Have you ever tried using 64-bit instructions, on a 64-bit
> machine, but in a 32-bit system?
Well, I've used 64 bit doubles and 128 bit Altivec vectors in a "32 bit
system". Works well.
> > If they are, then what is preventing you, as a compiler vendor, from
> > using them?
>
> Operating system support. I have no desire to try to recreate
> the operating system under my product.
I don't get this. What is missing from the operating system? So the OS
APIs are 32 bit. So what? I still use plenty of 8-bit and 16-bit
variables on a 32 bit system, because they're prefectly adequate for
many uses. 64 bit values would be handy for file sizes these days, but
the MacOS has had APIs that deal with that for years and years now. I
really can't see anyone losing sleep over a small inefficiency in
dealing with 64 bit values when talking to the file system.
> > Perhaps you'll need a different ABI to talk to OS code and libraries
> > than to your own code inside the application, but so what?
>
> You saw the code generation from my previous post.
Yeah, it sucked. I'm frankly surprised.
> The abi is either
> supported on the system or it is not. Currently, the 64-bit abi is
> not, so if you want to execute instructions within the current MacOSX
> system, you use the 32-bit abi.
When talking *to* the system, sure. But you can dowhatever you want
with your own non-exported functions. And compilers frequently do, on
all systems (but especially on x86).
> But not only that; if you try addressing more than 32-bits within that
> system, you'll either SEGV or wraparound, depending on how the
> page fault handlers treat extra bits in the upper half of a register.
> And address space is the most important reason for having 64 bits.
That's debatable. It's the most important for database vendors, but for
other uses it's the bigger integers that are the most important. How
long does a GC take on a >4GB heap?
Does it really not support >4GB processes? I know they take more than 4
GB of RAM, but I haven't seen anything more than that.
I take it that it *does* at least preserve the upper halves of the
registers on a context switch?
> > I really don't care what the C compiler calls various sized types -- all
> > portable code these days typedef's anything it cares about anyway. The
> > question is what can the hardware do?
>
> OK. So when does your 64-bit Dylan ship on it?
>
> :-)
Not before I get my hands on one, anyway. So far I've only seen one at
the NZ launch. it was only 1.6 Ghz, there were no developer tools on
it, and the only thing I was able to try was my standard
wet-finger-in-the-air Perl test:
time perl -e 'for($i=0;$i<=1000000;++$i){$t+=$i}print"$t\n"'
It was virtually identical to the speed of the Athlon 1800+ they give me
at work. That's certainly decent speed, but not earth-shattering given
the price of such an Athlon these days. The Mac probably pulls ahead on
real tasks though, due to the faster memory (it's been a *long* time
since you can say *that*).
In contrast, the fastest machines I have at home are an old 700 MHz
Athlon at 1.25 seconds, and a newish 1 GHz iMac at 1.5 seconds. They
perform near-identically on building d2c.
I'll probably be waiting until the next model G5 comes out and I can get
a dual 2 GHz at runout prices.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Duane Rettig <·····@franz.com> wrote:
> > No, all 64-bit operating systems have the same size longs. It is
> > because longs are defined to be the same size as a pointer.
> OK, good point, that *is* in the C standard
I'm quite sure the C standard doesn't state that longs are defined to
be the same size as pointers. Indeed C99 says that the result of
converting a pointer to an integer need not be in the range of values
of any integer type (section 6.3.2.3).
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
In article <··············@junk.nocrew.org>,
Lars Brinkhoff <·········@nocrew.org> wrote:
> Bruce Hoult <·····@hoult.org> writes:
> > Duane Rettig <·····@franz.com> wrote:
> > > No, all 64-bit operating systems have the same size longs. It is
> > > because longs are defined to be the same size as a pointer.
> > OK, good point, that *is* in the C standard
>
> I'm quite sure the C standard doesn't state that longs are defined to
> be the same size as pointers. Indeed C99 says that the result of
> converting a pointer to an integer need not be in the range of values
> of any integer type (section 6.3.2.3).
Whoops ... so I guess that's just another "all the world's a VAX"
assumption people make, then.
In which case Apple's compiler is perfectly within its rights to provide
64 bit access only via "long long".
The code generation could definitely do with some improvement though :-)
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Lars Brinkhoff <·········@nocrew.org> wrote:
> > Bruce Hoult <·····@hoult.org> writes:
> > > Duane Rettig <·····@franz.com> wrote:
> > > > No, all 64-bit operating systems have the same size longs. It is
> > > > because longs are defined to be the same size as a pointer.
> > > OK, good point, that *is* in the C standard
> > I'm quite sure the C standard doesn't state that longs are defined to
> > be the same size as pointers. Indeed C99 says that the result of
> > converting a pointer to an integer need not be in the range of values
> > of any integer type (section 6.3.2.3).
> Whoops ... so I guess that's just another "all the world's a VAX"
> assumption people make, then.
For that matter, there's no guarantee that all pointers are of the
same size, but perhaps all the world really IS a VAX in this regard. :)
> In which case Apple's compiler is perfectly within its rights to
> provide 64 bit access only via "long long". The code generation
> could definitely do with some improvement though :-)
My guess would be that the code generation per se is adequate, given
that GCC is constrained to generate code for Apple's legacy 32-bit
ABI. (Repeat: that's my guess.) With a proper 64-bit ABI, the
generated code would probably be much better.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> writes:
> Bruce Hoult <·····@hoult.org> writes:
> > Lars Brinkhoff <·········@nocrew.org> wrote:
> > > Bruce Hoult <·····@hoult.org> writes:
> > > > Duane Rettig <·····@franz.com> wrote:
> > > > > No, all 64-bit operating systems have the same size longs. It is
> > > > > because longs are defined to be the same size as a pointer.
> > > > OK, good point, that *is* in the C standard
> > > I'm quite sure the C standard doesn't state that longs are defined to
> > > be the same size as pointers. Indeed C99 says that the result of
> > > converting a pointer to an integer need not be in the range of values
> > > of any integer type (section 6.3.2.3).
> > Whoops ... so I guess that's just another "all the world's a VAX"
> > assumption people make, then.
>
> For that matter, there's no guarantee that all pointers are of the
> same size, but perhaps all the world really IS a VAX in this regard. :)
Yeah, C is the language of Vaxen. :-)
I misspoke earlier, and made a direct connection from longs to
pointers, which is not standardized. What _is_ standardized, though,
if defined, is a pair of typedefs called intptr_t and uintptr_t,
whose definition is the integer size to which a pointer type can
be assigned, and then assigned back again to the pointer type and
the resultant pointer types must compare equal (EQ in CL terms).
So I did a survey. All of the machines we currently support define
(u)intptr_t, and with the exception of Microsoft, which defines it
to be INT_PTR (which is itself defined in terms or pointer
assignability), the *nix boxes assign the intptr_t (and mutatis mutandis
for uintptr_t):
Linux: long (if WORDSIZE is 64)
Solaris: long (if LP64 or _I32LPX defined)
AIX: long (always)
HP long (always)
Alpha long (always)
SGI long (always)
In all of these situations the long data type happens to be 64 bits
when the compiler is compiling to a 64-bit abi. So I was incorrect
in a lawyerly sense, but empirically, I still stand by what I say,
that 64-bit longs are the norm for 64-bit binaries.
> > In which case Apple's compiler is perfectly within its rights to
> > provide 64 bit access only via "long long". The code generation
> > could definitely do with some improvement though :-)
>
> My guess would be that the code generation per se is adequate, given
> that GCC is constrained to generate code for Apple's legacy 32-bit
> ABI. (Repeat: that's my guess.) With a proper 64-bit ABI, the
> generated code would probably be much better.
My guess is that it would be as good as the code which AIX's gcc
generated for it. MacOSX's 32-bit abi is based on and very similar
to AIX's 32-bit abi, and I suspect that they'll go with AIX's 64-bit
abi, or at least start with it.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
[...]
> Linux: long (if WORDSIZE is 64)
> Solaris: long (if LP64 or _I32LPX defined)
> AIX: long (always)
> HP long (always)
> Alpha long (always)
> SGI long (always)
[...]
FreeBSD 4.x defined it as "int" for x86, and "long" for Alpha.
[...]
> My guess is that it would be as good as the code which AIX's gcc
> generated for it. MacOSX's 32-bit abi is based on and very similar
> to AIX's 32-bit abi, and I suspect that they'll go with AIX's
> 64-bit abi, or at least start with it.
FWIW, the OS X userland is based on FreeBSD (4.x, and bits taken from
5.x I believe). Mach is used for some scheduling and IPC. The
definitions on my FreeBSD are in "ansi.h". If you've installed the
developer's tools with OS X you may want to check the relevant
definitions in <machine/ansi.h>.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> Duane Rettig <·····@franz.com> writes:
> [...]
> > Linux: long (if WORDSIZE is 64)
> > Solaris: long (if LP64 or _I32LPX defined)
> > AIX: long (always)
> > HP long (always)
> > Alpha long (always)
> > SGI long (always)
> [...]
>
> FreeBSD 4.x defined it as "int" for x86, and "long" for Alpha.
>
> [...]
> > My guess is that it would be as good as the code which AIX's gcc
> > generated for it. MacOSX's 32-bit abi is based on and very similar
> > to AIX's 32-bit abi, and I suspect that they'll go with AIX's
> > 64-bit abi, or at least start with it.
>
> FWIW, the OS X userland is based on FreeBSD (4.x, and bits taken from
> 5.x I believe). Mach is used for some scheduling and IPC. The
> definitions on my FreeBSD are in "ansi.h". If you've installed the
> developer's tools with OS X you may want to check the relevant
> definitions in <machine/ansi.h>.
Actually, I had forgotten all about our Freebsd system; it has usually
followed the linux systems fairly closely. Yes, you're correct that it
defines intptr_t as int, just like some of the other 32-bit systems
do. I don't know of any 64-bit support Freebsd has or is planning,
unless they plan to backport some of Apple's stuff once they get that
working.
I also had looked up, but forgotten to mention, MacOSX's stand on
the issue. It looks like since at least MacOSX 10.1, intptr_t
has been defined as long (a departure from FreeBSD). So it looks
like they intend to carry on the tradition of using longs to track
the natural word size.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Actually, I had forgotten all about our Freebsd system; it has
> usually followed the linux systems fairly closely. Yes, you're
> correct that it defines intptr_t as int, just like some of the
> other 32-bit systems do. I don't know of any 64-bit support
> Freebsd has or is planning, unless they plan to backport some of
> Apple's stuff once they get that working.
[...]
I believe Alpha support is 64-bit. I know in the 5.x series there are
ports to the x86-64 and UltraSPARC, but I don't know which mode
(32/64) they run in.
There's also a PowerPC port underway.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
In article <···························@copper.ipg.tsnz.net>,
Bruce Hoult <·····@hoult.org> wrote:
>In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
>>
>> You saw the code generation from my previous post.
>
>Yeah, it sucked. I'm frankly surprised.
Not that I really want to get into this "discussion" but ...
The code generation is much better if you turn on some optimization flags.
On an fft code I was using, gcc-3.3 from Apple with the -fast flag on a G4
generated code that ran 10% faster than IBM's recently released xlc with -O4.
Brad Lucier
···@cs.purdue.edu (Bradley J Lucier) writes:
> In article <···························@copper.ipg.tsnz.net>,
> Bruce Hoult <·····@hoult.org> wrote:
> >In article <·············@beta.franz.com>,
> > Duane Rettig <·····@franz.com> wrote:
> >>
> >> You saw the code generation from my previous post.
> >
> >Yeah, it sucked. I'm frankly surprised.
>
> Not that I really want to get into this "discussion" but ...
>
> The code generation is much better if you turn on some optimization flags.
> On an fft code I was using, gcc-3.3 from Apple with the -fast flag on a G4
> generated code that ran 10% faster than IBM's recently released xlc with -O4.
Right; I didn't use any of the optimization flags, and I'm sure that better
code could have been generated. But the point was not that the code
was inefficient, but that the code was _constrained_ to be inefficient
by the 32-bit abi which allows only 32 bits to be passed in by a
register, even if the register has 64-bits. This constraint leads to
extraoridnary efforts in order to use the 64-bit instructions, which
were designed to be used most efficiently with a 64-bit abi.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> I don't get this. What is missing from the operating system? So the OS
> APIs are 32 bit. So what? I still use plenty of 8-bit and 16-bit
> variables on a 32 bit system, because they're prefectly adequate for
> many uses. 64 bit values would be handy for file sizes these days, but
> the MacOS has had APIs that deal with that for years and years now. I
> really can't see anyone losing sleep over a small inefficiency in
> dealing with 64 bit values when talking to the file system.
That's not the whole of it. The G5 is nice in one way because you
don't need to be in a special "long" mode to do 64-bits, but it can't
do anything about the fact that the OS-level libraries are still
32-bits. Say you compile your code to use 64-bit operations. Now, say
you've got a pointer somewhere above the 4GB 32-bit boundry. You want
to pass that memory to a system call, to say write to a file. What do
you do now? The 32-bit FS code can't handle the > 4GB pointer. If
you're masochistic enough, you can copy the data down to a < 4GB
trampoline, and write it that way, but that's a giant pain, and quite
a performance loss. Otherwise, you have to make sure that any datum
that's going to be passed to a system call is in the < 4GB range. I
don't want to think of the type of compiler analysis you've got to do
at this point. Also, there is really little to gain here. 64-bit
integers are the least interesting of the G5's features (though, maybe
d2c would like it if descriptor_t's could be held in one 64-bit
register?). Its not like the AMD64 architecture where 64-bit mode is
much faster (no segmentation, lots of legacy cruft removed, 8 more
visible registers, etc). The real gain is the access to > 4GB of
memory. If you can't do that, there is little gain from 64-bit mode,
and a lot of potential losses (larger pointers + larger integers =
less effective cache size).
> Does it really not support >4GB processes? I know they take more than 4
> GB of RAM, but I haven't seen anything more than that.
They couldn't, without compiling their libraries for 64-bit mode. They
can, however, do something like what Windows does on x86 machines with
> 4GB of memory. You've got an addressing window (think
bank-switching) to access more than 4GB of memory from a single
process, but not at the same time. Also, the OS can allocate 4GB per
process, but from a pool of 8GB of physical memory, so if you have
more than one process, you can take advantage of the large memory
support.
Duane Rettig <·····@franz.com> writes:
[...]
> But not only that; if you try addressing more than 32-bits within
> that system, you'll either SEGV or wraparound, depending on how the
> page fault handlers treat extra bits in the upper half of a
> register. And address space is the most important reason for
> having 64 bits.
[...]
It may be like the PAE system on x86: the hardware/addressing
supports more than 32-bits, the OS can use the extra memory if
designed to, but userland processes still are limited to 32-bits.
I believe this was discussed in comp.arch when the G5s were first
announced but I can't remember details (going to Groups.Google the
thread in question is 303 messages long).
Doing a quick perusal it seems that it has 42 bits for physical
addressing [1] so it may simple a compiler issue since the CPU should
be able to support "large" address spaces. Again from that thread,
PowerPCs are supposed to have 53 bits of virtual address space [2].
Ars Technica also has a good write-up on the G5/PowerPC 970 at
[2]. And the "official" info for the PowerPC 970 is at [4].
Going to the presentation from the MPF 2002 conference [5] where IBM
originally released the 970, page 10 of the PDF says:
* 64-bit advantages
- Driven by need to address larger memory spaces
- Performance advantage for data intensive applications
- Enable new 64-bit solutions
* Native 64-bit mode
- 64-bit fixed point processing
- 64-bit effective addresses
- 42-bit real addresses
- Segment lookaside buffer caches segment table entries
[...]
It may simply that the "64-bitness" is not fully used yet, but it's
on the chip for the future (and for marketing?). <shrug>
[1] http://groups.google.com/groups?selm=MPG.196245688c930879899ed%40enews.newsguy.com
[2] http://groups.google.com/groups?selm=christian.bau-7DFB01.17054626062003%40slb-newsm1.svr.pol.co.uk
[3] http://arstechnica.com/cpu/03q1/ppc970/ppc970-0.html
[4] http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_970_Microprocessor
[5] http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> It may simply that the "64-bitness" is not fully used yet, but it's
> on the chip for the future (and for marketing?). <shrug>
That's what it sounds like. And, there's special support for it in
PhotoShop. I could see it being worth-while to code up
per-application support for a few special apps, like PhotoShop. But
from the general-purpose language perspective, it sounds pretty bad.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bruce Hoult <·····@hoult.org> writes:
[ 64 bit long ]
> There are perfectly good reasons for not doing that, such as source code
> compatability with legacy (aka "broken") code that expects particular
> sizes. I'm sure there is a *lot* of that out there.
Not to disagree, but there's a lot less than there used to be. Pretty
much all the code in a Linux distribution (and if you consider Debian,
that's a /lot/ of code) is 64 bit clean these days: the Alpha has been
running 64 bit Linux for more than five years.
(Admittedly, SBCL is not yet in this "most" - though we're working on
it. Latest is at http://www.advogato.org/person/crhodes/ )
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Duane Rettig <·····@franz.com> writes:
> In this case r3 and r4 constitute the first long long argument, and
> r5/r6 make the second argument. If you follow it through, a 64-bit
> value is being built from the two 32-bit values each, and the 64-bit
> instructions are used intermediately to calculate the result (which
> is then split up into two 32-bit values again to pass back through r3
> and r4, rather than one 64-bit value in r3).
When you mentioned long long in your previous post, I had a sickening
feeling this would be the case. I didn't want to ask then because I
was afraid you would confirm it.
The Win32 API allows access to huge files in much the same way. The
API call takes two separate int32 args that consist of a low word and
high word. That is how you end up with 64 bit file access. I'm sure
that doesn't help with memory mapped files as the OS is still 32bit.
I take it that libc stdio facilities are similarly contaminated. Or
is there a POSIX way to access files that are larger than 4Gb on a
64bit or even 32bit machine? I always figured that simulating the old
and painful segmented memory architecture would end up being in order.
Apple claims that the G5 can take 8Gb of system memory. If it doesn't
use 64bit address spaces, is it doing some sort of translation,
leaving applications access to only a 32bit address space?
It seems so old school to have to treat the machine like it only has a
finite amount of memory :-/
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Classified as a solid class B shooter in NRA Rifle Silhouette
David Steuber <·············@verizon.net> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > In this case r3 and r4 constitute the first long long argument, and
> > r5/r6 make the second argument. If you follow it through, a 64-bit
> > value is being built from the two 32-bit values each, and the 64-bit
> > instructions are used intermediately to calculate the result (which
> > is then split up into two 32-bit values again to pass back through r3
> > and r4, rather than one 64-bit value in r3).
>
> When you mentioned long long in your previous post, I had a sickening
> feeling this would be the case. I didn't want to ask then because I
> was afraid you would confirm it.
Confirmed, unfortunately.
> The Win32 API allows access to huge files in much the same way. The
> API call takes two separate int32 args that consist of a low word and
> high word. That is how you end up with 64 bit file access. I'm sure
> that doesn't help with memory mapped files as the OS is still 32bit.
Correct.
> I take it that libc stdio facilities are similarly contaminated. Or
> is there a POSIX way to access files that are larger than 4Gb on a
> 64bit or even 32bit machine? I always figured that simulating the old
> and painful segmented memory architecture would end up being in order.
As I understand it, they have extended file system support (like most
32-bit operating systems).
> Apple claims that the G5 can take 8Gb of system memory. If it doesn't
> use 64bit address spaces, is it doing some sort of translation,
> leaving applications access to only a 32bit address space?
I suspect so - the only other way I could imagine them doing this is
by virtue of the dual-processors; if each processor got its own
4 Gb of memory, it could total up to 8 Gb. Seems unlikely, though.
> It seems so old school to have to treat the machine like it only has a
> finite amount of memory :-/
We went through the same processes in the 16-to-32 bit transitions.
Back then, 32-bits was a huge amount of memory - unimaginable. In the
late 70's, I was writing and running a program on a Univac 1108 and
I was chewed out by the system staff for using up all of the core
memory during my run - a whopping 100 Kbytes.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Christopher Browne <········@acm.org> writes:
> But if the OS limits you to 4GB of memory per process, I don't see how
> "user code" can overcome this. That is probably the most vital aspect
> of 64 bit support, in these "memory-bloated" days.
Do you use a lot of computer with more than 4GB of RAM?
Of course, it would be clumsy, but an application can take advantage
of the processor without the OS helping.
Anyway, I was hypothezing about what was in the mind of Apple
marketroids who don't realize that they're selling a true OS now and
who still react like with the old MacOS and its transitions. At that
time, they could sell a PowerPC machine with an OS mainly still in
680x0 code, and let the application run full speed ppc code while big
parts of the system still crawled.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.