Mike and Ward, what next?

[Roelf Toxopeus]

hi,
I hope you're willing/able to comment on recent events,
(for those wondering: Apple dumped PPC for Intel).
Any roadmap?

regards
-Roelf

[Erik]

I posted a similar meesage on the "Powermops Plans" thread. From what
I've been reading on the messageboards, it's not a wholesale
transition. Apparently Apple released a press release stating that it
was the mid-range Macs that were getting the Intel chips (haven't read
it myself, though). If that's true, the high-end Macs are staying
PowerPC, and mid-range/laptop Macs are getting Intel.

Isn't Win32Forth public domain? Maybe that can help ease any kind of
restructuring to the Mops' internals...

Erik

[Roelf Toxopeus]

Post by Erik
I posted a similar meesage on the "Powermops Plans" thread. From what
I've been reading on the messageboards, it's not a wholesale
transition. Apparently Apple released a press release stating that it
was the mid-range Macs that were getting the Intel chips (haven't read
it myself, though). If that's true, the high-end Macs are staying
PowerPC, and mid-range/laptop Macs are getting Intel.

it starts next year and full switch in 2007
http://www.thinksecret.com/news/wwdc05keynote.html

also interesting re Jobs's motives:
http://www.thinksecret.com/news/wwdc05cnbc.html

[Erik]

It's frustrating that Jobs plays the cards so close to his chest,
although I do understand why. I hope this spurs the creation of a lot
of great products; otherwise the Mac may be seen as just another PC.

What I'm worried about is the nightmare it's going to be to switch Mops
to an Intel architecture. Doesn't the Pentium series have fewer
registers than the PowerPC? Isn't x86 assembly supposed to be a mess?

On the other hand, this would be a good time to move Mops to a Mach-O
native format. I can't recall the link, but I remember a blog
somewhere where a developer was griping that Mach-O was a format
optimized for the x86 architecture, not PPC.

Erik

[Erik]

Post by Erik
On the other hand, this would be a good time to move Mops to a Mach-O
native format. I can't recall the link, but I remember a blog
somewhere where a developer was griping that Mach-O was a format
optimized for the x86 architecture, not PPC.
Erik

Just to add to what I wrote above, I found this interesting quote from
the comp.sys.mac.system newsgroup. It regards Rosetta, the PowerPC
emulator for the new Mac/Intel CPUS:

-------------------------------

Rosetta does not run the following:

- Applications built for Mac OS 8 or 9
- Code written specifically for AltiVec
- Code that inserts preferences in the System Preferences pane
- Applications that require a G4 or G5 processor
- Applications that depend on one or more kernel extensions
- Kernel extensions
- Bundled Java applications or Java applications with JNI libraries
that can¹t be translated

-------------------------------

It apparently came from:
https://developer.apple.com/do cumentation/MacOSX/Conceptual/
universal_binary/universal_binary.pdf

If that's true then Mops has to change once the Intel CPUs are in full
force. Anything other than Mach-O format won't be supported.

Erik

[ward mcfarland]

Post by Erik
Just to add to what I wrote above, I found this interesting quote from
the comp.sys.mac.system newsgroup. It regards Rosetta, the PowerPC
-------------------------------
- Applications built for Mac OS 8 or 9
- Code written specifically for AltiVec
- Code that inserts preferences in the System Preferences pane
- Applications that require a G4 or G5 processor
- Applications that depend on one or more kernel extensions
- Kernel extensions
- Bundled Java applications or Java applications with JNI libraries
that can't be translated
-------------------------------
If that's true then Mops has to change once the Intel CPUs are in full
force. Anything other than Mach-O format won't be supported.

Jobs makes it sound like he has a smooth transition all mapped out, but
this is a much bigger change than 68k->PPC.

Obvious deductions are that CFM Carbon will be gone with the release of
"leopard" as will Classic and CFM support.

Jobs generously offers to sell mid and upper tier developers a 4.6 GHz
P4 Mac for $995 (plus $500 for Select membership). So we need yet
another machine on hand for developing and testing.


GForth is currently Mach-based. But as Erik pointed out, the completely
different register model and optimizing methods likely will make
PPC-based Forths dog-slow when run under Rosetta (see page 67 of the
Universal Binary document). And Rosetta is not like the old PPC-based
68k emulator - not all PPC code will run under Rosetta.

Since Jobs really wants developers to convert to Universal Binary
format, other issues come up. To build a Universal Binary Forth, it
sounds like XCode will automatically make 2 code images, one for PPC and
one for x86. This will make it really tough to do an interactive
compiler that can make a snapshot/turnkey that can run on the "other"
platform as well (assuming Apple even documents the format of a
Universal Binary). So for those of us who are doing our own
compiling/optimizing, it means two versions as far as I can tell.



... maybe we should go back to a tokenized model with the token
displatching engine written as a Universal Binary and just abandon
including an assembler or attempting to do non-trivial optimizing...

My comment for the day is "ugh"

-- w

[ward mcfarland]

...lest I sound too negative, I have been recollecting other new
exciting directions announced at WWDC as THE way of the future. Some
took up almost the entire WWDC, a couple took up two successive WWDC's.

Raise your hand if you recall:
QuickRing
QuickDrawGX
OpenDoc (don't get me started on that one)
Copland
Yellow Box


With a *target* release date of "late 2007", I am not going to spend too
much time fretting. For all I know, Steve-o was mad at IBM for working
on an X-box PPC with better specs than current ones available for Mac.
If IBM comes out with a 3 GHz PPC soon, we may see the Intel deal put
back on the shelf.

-- w

[Erik]

Post by ward mcfarland
For all I know, Steve-o was mad at IBM for working
on an X-box PPC with better specs than current ones available for Mac.
If IBM comes out with a 3 GHz PPC soon, we may see the Intel deal put
back on the shelf.
-- w

I don't know... Intel is too big to be snubbed like that. Besides,
Jobs had a Pentium Mac running during the presentation. And I think he
was giving away Xcode 2.1, which makes the Universal Binaries. This
has a real feeling of permanence to it.

Erik

[Gregory Weston]

Post by Erik

Post by ward mcfarland
For all I know, Steve-o was mad at IBM for working
on an X-box PPC with better specs than current ones available for Mac.
If IBM comes out with a 3 GHz PPC soon, we may see the Intel deal put
back on the shelf.
-- w

I don't know... Intel is too big to be snubbed like that. Besides,
Jobs had a Pentium Mac running during the presentation. And I think he
was giving away Xcode 2.1, which makes the Universal Binaries.

Xcode 2.1 was made available for download Monday night and handed to
attendees on disc after the keynote.

G

[Gregory Weston]

Post by ward mcfarland
...lest I sound too negative, I have been recollecting other new
exciting directions announced at WWDC as THE way of the future. Some
took up almost the entire WWDC, a couple took up two successive WWDC's.
QuickRing

Nope. Never even heard of that name.

Post by ward mcfarland
QuickDrawGX
OpenDoc (don't get me started on that one)

I recall both of those very well. What I recall is that Apple spent
_years_ hawking them and got virtually no interest from developers or
users. I recall historically Mac-hostile publications talking up OpenDoc
as obviously superior to any other component model being pushed at the
time. I recall a few developers shipping QDGX apps in parallel to the
traditional QD versions but with more features and at a lower cost
(reflecting the lower development cost) and then killing the GX builds
in the next release because people weren't buying them. And I recall,
after years of neglect from anyone outside of Apple and the quite
reasonable axing of the technologies under those circumstances, people
coming out and saying "but I was just going to use that...."

Post by ward mcfarland
Copland

Thankfully dead. Would have been much more disruptive to both users and
developers than OS X was.

Post by ward mcfarland
Yellow Box

Unfortunately dead. Or at least comatose.

Post by ward mcfarland
If IBM comes out with a 3 GHz PPC soon, we may see the Intel deal put
back on the shelf.

Unlikely. It's not about what's available now or what's planned for the
next twelve months. It's about what's expected for the next 5 years and
track records on meeting expectations.

[Andy Dent]

Post by Gregory Weston

Post by ward mcfarland
QuickRing

Nope. Never even heard of that name.

from a quick Google
http://www.worldhistory.com/wiki/Q/QuickRing.htm
"
QuickRing was a gigabit-rate interconnect that combined the functions of
a computer bus and a network. It was originally designed at Apple
Computer as a multimedia system to run "on top" of existing local bus
systems inside a computer ..."

Post by Gregory Weston

Post by ward mcfarland
QuickDrawGX
OpenDoc (don't get me started on that one)

I recall both of those very well. What I recall is that Apple spent
_years_ hawking them and got virtually no interest from developers or
users.

I can give you at least two major Apple screwups with these technologies:
1) QuickDrawGX was an OPTIONAL install with significant memory overhead.
By making it optional and AFAIK off by default, it didn't make it into
the installed base iin sufficient numbers.

2) OpenDoc shipped without any complete developer tools beyond the C API
because the core development team didn't believe (*) in OO frameworks
and they weren't a priority. This at a time when MacApp, TCL &
PowerPlant were dominating app development.

3) Furthermore, Apple didn't come out with a clear business strategy for
how developers could make use of OpenDoc and failed to push into the
business market where it would have been most useful.

The final nail in OpenDoc's coffin, I think, was the disastrous
Novell/Wordperfect takeover as they were a major OD developer tasked
with the Windows side.

(*) I was doing a major cross-platform tool options consultancy at the
time and went on the OpenDoc programming course to help make my mind up.
The above info comes from the presenter.

[Erik]

Post by ward mcfarland
Jobs makes it sound like he has a smooth transition all mapped out, but
this is a much bigger change than 68k->PPC.
Jobs generously offers to sell mid and upper tier developers a 4.6 GHz
P4 Mac for $995 (plus $500 for Select membership). So we need yet
another machine on hand for developing and testing.

At the very least, the transition is intended to be over a 2 year
period. So until about, say, June '06, Intel Macs would be in the
minority. Unless a software item needs wide distribution,
incompatibilities should be somewhat manageable until then. Hopefully.

Post by ward mcfarland
... maybe we should go back to a tokenized model with the token
displatching engine written as a Universal Binary and just abandon
including an assembler or attempting to do non-trivial optimizing...

You would only have to put up with it until the transition was
complete; then you could go ahead and work with the processor-dependant
code. I wonder if there's an opportunity here to take a cue from the
Java VM or TCL interpreter. Create a VM (written in C or ObjC) with
the core wordset, but extensible by shared libraries. A text or
bytecode stream could be fed to it much the same way as Java, creating
a portable base system to customize for a given platform. I don't know
how you would be able to create turnkey apps or shared libraries with
it though.

Erik

[Gregory Weston]

Post by Erik

Post by ward mcfarland
Jobs makes it sound like he has a smooth transition all mapped out, but
this is a much bigger change than 68k->PPC.
Jobs generously offers to sell mid and upper tier developers a 4.6 GHz
P4 Mac for $995 (plus $500 for Select membership). So we need yet
another machine on hand for developing and testing.

At the very least, the transition is intended to be over a 2 year
period. So until about, say, June '06, Intel Macs would be in the
minority.

Uh. Until about June 2006 Intel Macs will be essentially non-existent in
the user base. The transition starts roughly a year from now and is
announced to take about 18 months for the whole line. I don't think
Intel makes up even a simple majority of the installed based until
mid-2008 and that's aggressive.

G

[Erik]

Post by Gregory Weston
Uh. Until about June 2006 Intel Macs will be essentially non-existent in
the user base. The transition starts roughly a year from now and is
announced to take about 18 months for the whole line. I don't think
Intel makes up even a simple majority of the installed based until
mid-2008 and that's aggressive.

Huh. For some reason I had the impression they were going to start
rolling out before June '06. Maybe I was confusing that with the
developer rentals they are doing.

In any case, my point is that there is time to consider how to handle
this with regards to Mops.

Erik

[Gregory Weston]

Post by ward mcfarland
Jobs generously offers to sell mid and upper tier developers a 4.6 GHz
P4 Mac for $995 (plus $500 for Select membership).

Not sell. Rent. It has to go back by the end of 2006.

G

[Erik]

Post by ward mcfarland
... maybe we should go back to a tokenized model with the token
displatching engine written as a Universal Binary and just abandon
including an assembler or attempting to do non-trivial optimizing...
My comment for the day is "ugh"
-- w

What would happen if you used AS, the assembler that's included with
the OS? If my understanding is correct, AS is the optimized version of
GAS, the GNU Assembler. I believe GAS tries to keep instructions
consistent across architectures, so you would have some measure of
portability and optimization at the same time. It's just a guess,
though. I'm not that well-versed with assembly.

Erik

[ward mcfarland]

Post by Erik

Post by ward mcfarland
... maybe we should go back to a tokenized model with the token
displatching engine written as a Universal Binary and just abandon
including an assembler or attempting to do non-trivial optimizing...

What would happen if you used AS, the assembler that's included with
the OS? If my understanding is correct, AS is the optimized version of
GAS, the GNU Assembler. I believe GAS tries to keep instructions
consistent across architectures, so you would have some measure of
portability and optimization at the same time. It's just a guess,
though. I'm not that well-versed with assembly.

I prefer Forth-based Assemblers, myself ;-)

One issue is building the core of a x86 Forth, which could be done in
any ASM, I suppose.

I was referring to the difficulty of providing a single Forth that could
build a Universal Binary snapshot/turnkey. Having to do two compiles to
aaccomplish that sort of interferes with the incremental compile/test
style we all know and love.

Any assembly used in user source would have to be redone in the other
CPU's instruction set, meaning one source code could not be used for
both builds.

Non-minimal optimization for PPC and x86 would be entirely different as
well.

A tokenized Forth with some load or run time optimization is an
interesting alternative, although it starts to sound like RPN Java.

-- w

[Mike Hore]

Hi folks,

I'm coming in a bit late here because for a while I just didn't
take all this stuff seriously -- but it's now starting to look
a bit more serious. But like Ward I've been around long enough
to see many "latest and greatest" technologies disappear without
a trace.

But anyway, as I said on the other thread, I'm no great Intel
fan. Targetting a different processor is a big job,
whichever way you look at it. For most developers it's
"just" a matter of recompiling your (C) code since good
C optimizing compilers exist on all platforms. But even
then there are always lots of "issues" which come up.

But if you're the compiler writer, it's a whole different
ball game. And in my case Mops has been a basically spare
time project though I've been able to incorporate some of
it into my paid work. But the question is whether at this
stage of my life I'm really interested in doing yet another
code generator, for a processor with only half the
registers of the PowerPC, and whether I'd enjoy it enough
for it to be a project I'd really want to spend serious
time on.

Also I'd need access to a machine to test on, and I'm likely
to be spending most time in the next few years out in a remote
location. So as I said on the other thread, all things
considered, I'd probably prefer to pass the ball
to someone else.

Cheers, Mike.

----------------------------------------------------------------
Mike Hore ***@OVE.invalid.icasolution.com.au
----------------------------------------------------------------

[Erik]

Post by Mike Hore
Also I'd need access to a machine to test on, and I'm likely
to be spending most time in the next few years out in a remote
location. So as I said on the other thread, all things
considered, I'd probably prefer to pass the ball
to someone else.
Cheers, Mike.

Well, regardless of what happens, thanks for writing Mops in the first
place. I'm a hobbyist at programming, but I remember taking my first
programming course some years back in C++. I still remember the
frustration of trying to track down a missing ';' or an 'S' instead of
's', and so forth. Mops made things much easier in that regard, and I
got quite addicted to the interactive feedback. Good luck in your
endeavors!

Erik

[david]

Post by Roelf Toxopeus
hi,
I hope you're willing/able to comment on recent events,
(for those wondering: Apple dumped PPC for Intel).
Any roadmap?
regards
-Roelf

This just came up on c.l.f. Is is it possibly an alternative fork
following the dumping?

david

Post by Roelf Toxopeus

Reading about Forth multi-tasking in Stephen Pelc's book, it seems to
me that Forth does not yet deal with the problems of multiple tasks
running on different processors in a shared-memory machine.

Could be wrong, but I kind of remember seeing somewhere... google
"parallel forth" oh yes, here it is, it's Marcel Hendrix & Co...

http://home.iae.nl/users/mhx/i4threads.html

And even on ultratechnology...

http://www.ultratechnology.com/4thpar.html

I am guessing but with a native win32 forth compiler one could
probably nearly always get away with preemptive multitasking calling
the underlying OS but how messy this is, I do not know (yet). I
believe VFX has a few words to help with this but I've yet to mess
with multithreading in forth.

What is more interesting I think than mutlicore x86's is this new Cell
critter which I gather has a rather different paradigm compared to
traditional multicores.....

There is not much out on how to program one of these yet... but I
would reckon that initial development'll probably take the form of a c
or c++ with parallel/SIMD extensions, or even plain asm.

What do the expert compiler implementers think of the challenges of
adapting a forth to fully take advantage of Cell...

PS3's should be cheap-ish... It seems like a fun idea...

Cheers,
Rob

[Mike Hore]

Post by david
...
What do the expert compiler implementers think of the challenges of
adapting a forth to fully take advantage of Cell...

At least Cell is based on the PowerPC.

But how to put in parallel constructs -- off the top of my head
I wouldn't have a clue. But I'd rather this, than retargetting
for a different CPU.


Cheers, Mike.


----------------------------------------------------------------
Mike Hore ***@OVE.invalid.bigpond.com
----------------------------------------------------------------

[robert spykerman]

On Thu, 16 Jun 2005 11:02:04 -0400, david <***@DELlandowne.org>
wrote:
<edited>

Post by david
This just came up on c.l.f. Is is it possibly an alternative fork
following the dumping?

Post by david
What is more interesting I think than mutlicore x86's is this new Cell
critter which I gather has a rather different paradigm compared to
traditional multicores.....
There is not much out on how to program one of these yet... but I
would reckon that initial development'll probably take the form of a c
or c++ with parallel/SIMD extensions, or even plain asm.
What do the expert compiler implementers think of the challenges of
adapting a forth to fully take advantage of Cell...
PS3's should be cheap-ish... It seems like a fun idea...

Not quite an alternative fork, I don't think.

I was just wondering out aloud about parallel forths and whether it
would be difficult to program a cell, particularlly in forth.

I am personally quite peeved apple dumped PPC for intel, but I can
understand their reasons why.

Even with the limited amount of registers an x86 has, in still seems
on average to trounce PPCs on performance (the monster P4's, FX's and
even overclocked Pentium M's - see tom's hardware) and probably
efficiency as well (Pentium M and further iterations of same).

However, I believe the PPC SIMD technology is superior, and the
results of parallelized benchmarks may show this, and at the real
extreme, if you believe the numbers, the claimed performance of Cell.

Cell is going to be interesting, thank God it probably won't die
prematurely (PS3 Yeah!)

How forth is going to be put to writing APUlets I have no idea, I can
only see this happening in low-level C/assembly. One reason I am
unsure - I don't know how a 'dictionary' can be implemented. One for
each subprocess? One for each APU?

I would REALLY have loved to see Apple adopt Cell. It looks like a
bastard of a chip to program and would probably require a new OS, but
hey, that's real innovation. That's going to take real balls.

But Apple aren't up to it.

Sony are.

So I am going to buy a PS3 instead, because firstly Sony will probably
foot some of the hardware cost as most game console producers do,
making it reasonably cheap. And I know some dude out there will
probably figure out how to put a unix or something on it... And then,
voila, Cell workstation...

As an aside, x86 assembly isn't too bad, but this is coming from one
who is just trying to learn PPC assembly in his spare (non-existent)
time on MOPS and thinks while on the one hand, it's neat to have
instruction words the same length, figures it's a pain having to code
2 instructions to load one machine word into a register.

x86's also tend to out-of-order a lot more for you, than on PPC's
where I believe you have to really think ahead much more..

x86's FPU is a load of b*ll*cks compared to PPC but it is a 7 element
stack like critter like forth.

If you want to jump the wagon to learning x86 and keep doing forth,
might I recommend Stephen Pelc's excellent VFX

http://www.mpeltd.demon.co.uk/arena.htm

If you like MOPS, you will LOVE VFX.... I have to say his code
generator IMO is about the best on x86 platforms. The assembler is
pretty easy to use as well which is a definite plus, and stringing
assembly into forth is way easier I think than other forth win32
systems I have seen.

And if you ask you can get a free evaluation edition

One thing good about this whole apple debacle.

Wait 2 years and you will get a notebook computer with a pretty
exceptional build quality, will run OS X AND Windoze.

Hopefully it will HAVE at least TWO mice buttons. Geez.... For flip's
sake what WERE apple thinking with one button mice....

Anyway, that was a long rant

I hope CELL really strikes it, and NUTS to you, apple for dumping PPC.

Cheers

Rob

[Erik]

Hi!

Post by robert spykerman
Even with the limited amount of registers an x86 has, in still seems
on average to trounce PPCs on performance (the monster P4's, FX's and
even overclocked Pentium M's - see tom's hardware) and probably
efficiency as well (Pentium M and further iterations of same).

I remember when the news broke and chaos was reigning over on the
slashdot threads over this. I think there was some mention of the fact
that Intel CPUs have been getting more RISC-ish, but maintaining the
CISC instruction for one reason or another. I'm not much up on CPUs,
though, so I guess you have take that for what it's worth...

Post by robert spykerman
I would REALLY have loved to see Apple adopt Cell. It looks like a
bastard of a chip to program and would probably require a new OS, but
hey, that's real innovation. That's going to take real balls.

Referencing Slashdot again, I think there was some mention of the fact
that Cell is really not heading in the direction of desktop computing.
Something about how it doesn't do out-of-order branching or indexing or
some-such. Basically, it's heavily aimed in a specific direction that
game platforms can take advantage of, but not desktop computers.
Besides, aren't the Apple PPC CPUs and Cells both derivatives of IBM's
POWER CPUs? If it weren't for the expense and heat issues, I could see
Apple being all over that.

Post by robert spykerman
So I am going to buy a PS3 instead, because firstly Sony will probably
foot some of the hardware cost as most game console producers do,
making it reasonably cheap. And I know some dude out there will
probably figure out how to put a unix or something on it... And then,
voila, Cell workstation...

I think the Cell processor is going to be in every major console coming
out soon. Personally I'm wondering when someone will come out with a
"Hack the XBox" redux.

Post by robert spykerman
One thing good about this whole apple debacle.
Wait 2 years and you will get a notebook computer with a pretty
exceptional build quality, will run OS X AND Windoze.

I hope not. The Windows part, I mean. Dual-booting seems so against
the grain on a Mac (and a lot of people seem to be drooling over the
idea)... Virtual PC I can see, though.

Erik

[robert spykerman]

Post by Erik
Referencing Slashdot again, I think there was some mention of the fact
that Cell is really not heading in the direction of desktop computing.
Something about how it doesn't do out-of-order branching or indexing or
some-such. Basically, it's heavily aimed in a specific direction that
game platforms can take advantage of, but not desktop computers.
Besides, aren't the Apple PPC CPUs and Cells both derivatives of IBM's
POWER CPUs? If it weren't for the expense and heat issues, I could see
Apple being all over that.

For all we know cell may herald a significant padigm shift... It's a
simpler POWER chip yes, and not much out-of-ordering's not a big deal,
Could be wrong, but PPC's I believe have less out of ordering anyway
compared to intel chips to begin with.

Good compilers/asm programmers can make up this difference to some
extent I guess.

Post by Erik
I think the Cell processor is going to be in every major console coming
out soon. Personally I'm wondering when someone will come out with a
"Hack the XBox" redux.

Think they have some multicore 970 for the xbox not the cell, but
that's quibbling.

I'd probably see Cell in Toshiba CAT scanners soon - apparently an
unnamed biomedical company has already adopted cell for its diagnostic
imaging stuff. Probably Toshiba :)

Post by Erik

Post by robert spykerman
One thing good about this whole apple debacle.
Wait 2 years and you will get a notebook computer with a pretty
exceptional build quality, will run OS X AND Windoze.

I hope not. The Windows part, I mean. Dual-booting seems so against
the grain on a Mac (and a lot of people seem to be drooling over the
idea)... Virtual PC I can see, though.

Ah, remember what Bruce (Lee) said. Adopt what's useful, junk what's
useless to attempt to paraphrase him!

Use a Mac. Use a PC, use them for what they are. It's only a PC...

Apple does smart things... Apple ][ (yeah!).... Objective C is soooo
much nicer than C++... G5... well kinda...

Apple constantly does stupid things too, like one button mice, dumping
BeOS before it got a fair chance, bloating up OS X with too much eye
candy stuff... Stupid laptop battery tricks.... bad customer
support.. lots....

Cheers

Rob

[david]

Post by robert spykerman

Post by Erik
Referencing Slashdot again, I think there was some mention of the fact
that Cell is really not heading in the direction of desktop computing.
Something about how it doesn't do out-of-order branching or indexing or
some-such. Basically, it's heavily aimed in a specific direction that
game platforms can take advantage of, but not desktop computers.
Besides, aren't the Apple PPC CPUs and Cells both derivatives of IBM's
POWER CPUs? If it weren't for the expense and heat issues, I could see
Apple being all over that.

For all we know cell may herald a significant padigm shift... It's a
simpler POWER chip yes, and not much out-of-ordering's not a big deal,
Could be wrong, but PPC's I believe have less out of ordering anyway
compared to intel chips to begin with.
Good compilers/asm programmers can make up this difference to some
extent I guess.

Post by Erik
I think the Cell processor is going to be in every major console coming
out soon. Personally I'm wondering when someone will come out with a
"Hack the XBox" redux.

Think they have some multicore 970 for the xbox not the cell, but
that's quibbling.
I'd probably see Cell in Toshiba CAT scanners soon - apparently an
unnamed biomedical company has already adopted cell for its diagnostic
imaging stuff. Probably Toshiba :)

Post by Erik

Post by robert spykerman
One thing good about this whole apple debacle.
Wait 2 years and you will get a notebook computer with a pretty
exceptional build quality, will run OS X AND Windoze.

I hope not. The Windows part, I mean. Dual-booting seems so against
the grain on a Mac (and a lot of people seem to be drooling over the
idea)... Virtual PC I can see, though.

Ah, remember what Bruce (Lee) said. Adopt what's useful, junk what's
useless to attempt to paraphrase him!
Use a Mac. Use a PC, use them for what they are. It's only a PC...
Apple does smart things... Apple ][ (yeah!).... Objective C is soooo
much nicer than C++... G5... well kinda...
Apple constantly does stupid things too, like one button mice, dumping
BeOS before it got a fair chance, bloating up OS X with too much eye
candy stuff... Stupid laptop battery tricks.... bad customer
support.. lots....
Cheers
Rob

The Linux programming model for Cell

http://www-128.ibm.com/developerworks/linux/library/pa-cell/index.html?ca=drs-

The integration of support for the PowerPC Processing Element in one
of the next kernel releases will enable the use of a single kernel
binary for all current 64-bit PowerPC machines including Cell, Apple
Power Mac, and IBM pSeries.

They used a virtual file system to externalize the Synergistic
Processing Units.

[Stephen Pelc]

On Fri, 17 Jun 2005 19:44:23 +1000, robert spykerman

Post by robert spykerman
Even with the limited amount of registers an x86 has, in still seems
on average to trounce PPCs on performance (the monster P4's, FX's and
even overclocked Pentium M's - see tom's hardware) and probably
efficiency as well (Pentium M and further iterations of same).

I'm no PPC expert - I get the architecture manuals out for
an hour or two once in a while.

First, CPU clock rate is *not* really the issue. At present,
CPU clock rate is 5-10 times greater than memory bandwidth, so
which CPU is faster depends very much on the cache and memory
structure *and* on the application use of memory.

The current Intel P4 memory architecture is dire and very
much assumes the use of C-style linkers. In a random number
generator benchmark that uses a single variable, we saw a
variation of 7:1 according to the address of the variable.
The P4 seems to have pipelines in the range of 21-41 stages,
and so is very susceptible to branch target problems.

In most cases, the memory design is not specified by the
architecture. Most SPARCs are very good in this respect.

Post by robert spykerman
x86's FPU is a load of b*ll*cks compared to PPC but it is a 7 element
stack like critter like forth.
If you want to jump the wagon to learning x86 and keep doing forth,
might I recommend Stephen Pelc's excellent VFX
http://www.mpeltd.demon.co.uk/arena.htm
If you like MOPS, you will LOVE VFX.... I have to say his code
generator IMO is about the best on x86 platforms.

Blush. We spent a serious amount of time and money developing
the VFX code generator. Fortunately we managed to get a grant
for some of it. The results show that it was worthwhile. However,
we also designed VFX Forth for portability. There are fewer than
30 coded routines in the system, nearly all for startup and
O/S interfacing. The entire interface to the VFX code
generator is though COMPILE, and some internal data in the
dictionary headers.

When porting VFX Forth to another platform, changing CPU is
the least of the problems. The real work is in the binary
format, e.g. ELF, and in the operating system API interface.

I have not looked at source code for the Mac Forths, so I can't
comment on their porting issues, but providing that only the CPU
changes, the Forth kernel was designed for portability, and the
existing O/S kernel interfaces do not change, the job is quite
straight forward. Whether the authors have the energy for it
is another matter.

There are several quality Forths already for the Mac. I don't
see commercial success in MPE doing another except in
collaboration with an existing Mac organisation.

Stephen

--
Stephen Pelc, ***@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: [phone], fax: [phone]
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

[Erik]

Post by Stephen Pelc
When porting VFX Forth to another platform, changing CPU is
the least of the problems. The real work is in the binary
format, e.g. ELF, and in the operating system API interface.
I have not looked at source code for the Mac Forths, so I can't
comment on their porting issues, but providing that only the CPU
changes, the Forth kernel was designed for portability, and the
existing O/S kernel interfaces do not change, the job is quite
straight forward. Whether the authors have the energy for it
is another matter.

You'd have to dig up some info on the Mach-O file format. I found some
general overview information on Apple's website, but I don't think they
provide any API to create them aside from compilers like XCode and so
forth. So it would have to be by hand, so to speak.

As for the OS itself, the Objective C runtime supports bridging with
other languages so that ObjC classes (in this case Cocoa) can be
manipulated from outside. The API is C-based, so I don't know what
kind of effort it is to hook it up via assembly (which is what I assume
you would try to do).

Erik

[Mike Hore]

Post by Erik

Post by Stephen Pelc
When porting VFX Forth to another platform, changing CPU is
the least of the problems. The real work is in the binary
format, e.g. ELF, and in the operating system API interface.
I have not looked at source code for the Mac Forths, so I can't
comment on their porting issues, but providing that only the CPU
changes, the Forth kernel was designed for portability, and the
existing O/S kernel interfaces do not change, the job is quite
straight forward. Whether the authors have the energy for it
is another matter.

You'd have to dig up some info on the Mach-O file format. I found some
general overview information on Apple's website, but I don't think they
provide any API to create them aside from compilers like XCode and so
forth. So it would have to be by hand, so to speak.
As for the OS itself, the Objective C runtime supports bridging with
other languages so that ObjC classes (in this case Cocoa) can be
manipulated from outside. The API is C-based, so I don't know what
kind of effort it is to hook it up via assembly (which is what I assume
you would try to do).

The latest Mops release supports calling Objective-C methods,
if that's any help. I didn't do the hard work for this
myself, so I'd have to look up the source code to be able
to answer any nuts-and-bolts questions, but the source code's
all there in the release.

(www.PowerMops.org)

Cheers, Mike.


----------------------------------------------------------------
Mike Hore ***@OVE.invalid.bigpond.com
----------------------------------------------------------------

[Roelf Toxopeus]

Post by Erik

Post by Stephen Pelc
When porting VFX Forth to another platform, changing CPU is
the least of the problems. The real work is in the binary
format, e.g. ELF, and in the operating system API interface.
I have not looked at source code for the Mac Forths, so I can't
comment on their porting issues, but providing that only the CPU
changes, the Forth kernel was designed for portability, and the
existing O/S kernel interfaces do not change, the job is quite
straight forward. Whether the authors have the energy for it
is another matter.

You'd have to dig up some info on the Mach-O file format. I found some
general overview information on Apple's website, but I don't think they
provide any API to create them aside from compilers like XCode and so
forth. So it would have to be by hand, so to speak.
As for the OS itself, the Objective C runtime supports bridging with
other languages so that ObjC classes (in this case Cocoa) can be
manipulated from outside. The API is C-based, so I don't know what
kind of effort it is to hook it up via assembly (which is what I assume
you would try to do).

mmm, who says it has to be Cocoa? Is Carbon out?

To be sure we're talking about the same thing when we say Cocoa and
Carbon:
http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology
_Overview/MacOSXOverview/chapter_2_section_2.html#//apple_ref/doc/uid/TP4
0001067-CH205-TPXREF145

[Erik]

Post by Roelf Toxopeus
mmm, who says it has to be Cocoa? Is Carbon out?
To be sure we're talking about the same thing when we say Cocoa and
http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology
_Overview/MacOSXOverview/chapter_2_section_2.html#//apple_ref/doc/uid/TP4
0001067-CH205-TPXREF145

There's nothing wrong with Carbon. In fact I read an article somewhere
that Carbon was meant as a platform for alternative languages while
Cocoa was meant for Objective-C. But take a look at this:

http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html?http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ObjCRuntimeRef/chapter_1.4_section_2.html

Basically, you can access the Objective-C runtime using a small handful
of function calls. I'm assuming that you can access the ObjC
frameworks/classes from there. If that's correct, it would be easier
to build an Objective-C bridge than go through the whole list of Carbon
API calls.

That's the thought anyway. I would probably defer to anyone with more
extensive experience on this matter.

Erik

[Roelf Toxopeus]

Post by Erik
Basically, you can access the Objective-C runtime using a small handful
of function calls.

Yes, used that to see if one could access it from (Carbon)MacForth,
but never finished a general useful interface. Mops has one, though.

Post by Erik
I'm assuming that you can access the ObjC frameworks/classes from
there.

Using only the ObjC frameworks/classes could give you a very limited
experience of your Mac.

As an experiment you could use the Mops ObjC runtime interface to see
if you can access from within the ObjC runtime arbitrary functions from,
say, the QuickTime, OpenGL, Core Audio, or System frameworks (don't use
the direct framework call mechanism in Mops).
AFAIK these frameworks are not ObjC, at least their API's are C, but that
shouldn't matter. Cocoa applications import and call these functions the
same way a C app in Carbon would do (in so far I understood the source
codes :)

Post by Erik
If that's correct, it would be easier to build an Objective-C bridge
than go through the whole list of Carbon API calls.

There's no need to implement the whole list, a Forth like MacForth
doesn't anyway. It allows you to pick what you need from the Carbon
lib/framework or any of the underlying frameworks. Currently MF
accesses nearly all the frameworks (including Cocoa) in OS X via two
'bridges': a CFM calling sequence for Carbon and a MachO calling sequence
for the rest, easy.
A possible MF on the IntelMac would be MachO, using the one bridge,
sure, more easy.