waldorf@hpccc.HP.COM (Beverly Waldorf) (02/18/89)
New Mac Rumours
Okay...it seems that the scoop is pretty will known of the MacIIcx:
68030, 68882 at 16 Mhz.
3 Nubus Slots.
But has anybody heard anything about the Mac coming out in August?
Heres what I would like to see:
33 Mhz 68030 , 68882
25 Mhz Nubus clock (does anyone know if TI's Nubus Chip set
can run that fast?)
32 bit quickdraw.
Also, I've heard that Apple is rewriting the system software in C, implying
that the Mac could run off most any CPU platform. I've heard that
Apple engineers REALLY like AMD's 29000 processor. I've no details whether
they are planning to use it for a cpu platform, postscript engine, or
a quickdraw accelerator.
Anyone seen this future screamer?arwall@athena.mit.edu (Chumley Wood) (02/20/89)
From the rumor column in InfoWorld, I read that the IIcx would contain a Motorola 56001 DSP, DMA chips, and the 29000 implementing Quickdraw. Time, of course, will tell. ------------------------------------------------------------------------- | Anders Wallgren Back by popular demand: | | arwall@athena.mit.edu Bush-Noriega '88 - A Crack Team! |
holland@m2.csc.ti.com (Fred Hollander) (02/20/89)
In article <9344@bloom-beacon.MIT.EDU> arwall@athena.mit.edu (Chumley Wood) writes: >From the rumor column in InfoWorld, I read that the IIcx would contain >a Motorola 56001 DSP, DMA chips, and the 29000 implementing Quickdraw. > >Time, of course, will tell. I've also read in MacWeek that it will be priced between the II and the IIx. That's an awful lot of extras to still be priced below the IIx - you're only giving up 3 slots. >------------------------------------------------------------------------- >| Anders Wallgren Back by popular demand: | >| arwall@athena.mit.edu Bush-Noriega '88 - A Crack Team! | Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
folta@tove.umd.edu (Wayne Folta) (02/21/89)
In article <70405@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: "In article <9344@bloom-beacon.MIT.EDU> arwall@athena.mit.edu (Chumley Wood) writes: ""From the rumor column in InfoWorld, I read that the IIcx would contain ""a Motorola 56001 DSP, DMA chips, and the 29000 implementing Quickdraw. "" ""Time, of course, will tell. " "I've also read in MacWeek that it will be priced between the II and "the IIx. That's an awful lot of extras to still be priced below the "IIx - you're only giving up 3 slots. " It is difficult to keep the various proposed units seperate, but there are *three* machines coming up, aren't there: 1. IIz 3-slot IIx 2. IIcx Tower unit, top-of-the-line with $Mbucks price, and fancy hardware 3. ???? Laptop If I'm not mistaken, you are talking IIz price slot and IIcx features. Wayne Folta (folta@tove.umd.edu 128.8.128.42)
ra_robert@gsbacd.uchicago.edu (02/21/89)
In article <16051@mimsy.UUCP>, folta@tove.umd.edu (Wayne Folta) writes... [...] >It is difficult to keep the various proposed units seperate, but there are >*three* machines coming up, aren't there: > 1. IIz 3-slot IIx > 2. IIcx Tower unit, top-of-the-line with $Mbucks price, > and fancy hardware > 3. ???? Laptop >If I'm not mistaken, you are talking IIz price slot and IIcx features. Wait, the IIcx is the tower unit? That can't be right. I _hope_ that the IIcx (or whatever the 3 slot IIx is) will have more features than the IIx. I mean, 5 months will have passed between their introductions. BTW, I wouldn't be suprised if we saw more than these three by December. Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
wb1j+@andrew.cmu.edu (William M. Bumgarner) (02/21/89)
The Finder (and probably the System) is being rewritten in C++... The speed increases quoted are absolutely amazing. a little birdy told me... 'nuff said. b.bum wb1j+@andrew.cmu.edu
lauac@wheeler.qal.berkeley.edu (Alexander Lau) (02/21/89)
In article <9344@bloom-beacon.MIT.EDU> arwall@athena.mit.edu (Chumley Wood) writes: >From the rumor column in InfoWorld, I read that the IIcx would contain >a Motorola 56001 DSP, DMA chips, and the 29000 implementing Quickdraw. > >Time, of course, will tell. >------------------------------------------------------------------------- >| Anders Wallgren Back by popular demand: | >| arwall@athena.mit.edu Bush-Noriega '88 - A Crack Team! | From the BMUG rumor mill, I heard that the computer described above will be called the "Mac //ex", not the //cx, and it will not have the 56001 DSP. However, it will have at least a 25 MHz 68030 (if not 33 MHz) and the talk in the back row was that it will be Apple's NeXT-basher. Disclaimer: I call 'em as I see 'em. --- Alex {att,backbones}!ucbvax!qal.berkeley.edu!lauac
moriarty@tc.fluke.COM (Jeff Meyer) (02/22/89)
I read both the InfoWorld and MacWorld articles: I think this is how the new
models are supposed to appear:
1) Mac IIcx, released ~ April, basically a Mac IIx with only three slots.
This seems to be a lot more solid than a rumor.
2) Mac ??, InfoWorld's rumored super-duper Mac IIx, with DMA, a
faster-than-16Mhz-68030, a faster NuBus, etc. This is a rumor, but
InfoWorld gave a pretty specific accounting of what was going to be in
it.
3) Mac Laptop. According to Mac the Knife in MacWeek, there's been a
struggle between a 68000 version which is just about ready to go, and a
lighter 68030 version that is still under development. Sculley's claim
that a laptop will be out by this summer seems to indicate that the
68000 model is going to be the winner here.
On another subject entirely, it's a pity that Apple decided not to call the
Mac SE/30 the Mac SEx.
"Remember, these terrorists are professionals.
Highly trained and well equipped. With their own
set of silly religious beliefs."
---
Moriarty, aka Jeff Meyer
INTERNET: moriarty@tc.fluke.COM
Manual UUCP: {uw-beaver, sun, hplsla, thebes, microsoft}!fluke!moriarty
CREDO: You gotta be Cruel to be Kind...
<*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>t-jacobs@wasatch.UUCP (Tony Jacobs) (02/22/89)
In article <70405@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >I've also read in MacWeek that it will be priced between the II and >the IIx. That's an awful lot of extras to still be priced below the >IIx - you're only giving up 3 slots. > The February 7th article says "The IIcx is expected to be priced closer to the SE/30 than the Mac IIx." And the February 14th article says "...it is expected to carry a street price of about $4500 in its basic configuration, compared with about $4000 for the stripped-down Mac SE/30." From Apples price list (suggested Retail): Macintosh SE/30 w/Apple keyboard $4498 Macintosh II w/Apple keyboard $4998 - no monitor mind you Macintosh IIx w/Apple keyboard $7098 - again on monitor I guess being priced closer to the SE/30 only means just < (7098+4498)/2 = 5798 so if it were the same price as the Mac II it would be $800 closer to the SE/30 I personally think the IIcx is going to be way more popular than Apple expects. It wouldn't supprise me if fewer than 5 or 10% of Mac II owners use more than 1 slot. I believe there sales of the II & IIx will go way down and that the IIcx will also put a dent in their SE/30 sales too. That will probally vary depending on how close the price is to the SE/30. I've been waiting for the 3-slot to come out for over a year now. The main reasons I'm getting one is to use whatever monitor I want, small footprint, /030 processor. -- Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu
billkatt@sol.engin.umich.edu (billkatt) (02/22/89)
In article <sY0Almy00UgPMJmYsw@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >The Finder (and probably the System) is being rewritten in C++... The speed >increases quoted are absolutely amazing. > >a little birdy told me... > >'nuff said. > >b.bum >wb1j+@andrew.cmu.edu Get Real. They are written in Assembly language right now. NOBODY gets a speed up going to a higher level language. You are quoting speeds for the new system which reqires NEW applications written in object-oriented languages. That is comparing Apples and Oranges. Besides, I've used Apple's C++ and it creates a 30K application for a two line source program (i.e. 'cout << "hey"') It has a long way to go before it is good enough to base an operating system on. OOPS... Replace 'have used' with 'would have used if it existed' and 'creates' with 'would have created if it existed' and 'has a long way to go before it is' with 'would have a long way to go if it existed before it woule be' in all instances above. This message in no way indicates that Apple has or doesn't have a C++ compiler in Alpha testing. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
jas@cadre.dsl.PITTSBURGH.EDU (Jeffrey A. Sullivan) (02/22/89)
In article <sY0Almy00UgPMJmYsw@andrew.cmu.edu>, wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: > The Finder (and probably the System) is being rewritten in C++... The speed > increases quoted are absolutely amazing. > > a little birdy told me... Is this true? Does this mean Apple's reworking their system into an object-oriented architecture (yes oh yes oh please)? I'd think we'd hear more of this. If not, why the hell use C++? I'd love so much for this to be true. Is there any sharing of sources? -- .......................................................................... Jeffrey Sullivan | University of Pittsburgh jas@cadre.dsl.pittsburgh.edu | Intelligent Systems Studies Program jasper@PittVMS.BITNET, jasst3@cisunx.UUCP | Graduate Student
md32+@andrew.cmu.edu (Michael Joseph Darweesh) (02/22/89)
I believe that the Mac OS is written in Pascal. As a matter of fact, the ROM procedures and functions are definately written in pascal. If you have a source, please enlighten me, it is possible that I'm wrong... Mike Darweesh md32@andrew.cmu.edu Carnegie Mellon
billkatt@sol.engin.umich.edu (billkatt) (02/23/89)
In article <EY0c4cy00hkj0xJJwY@andrew.cmu.edu> md32+@andrew.cmu.edu (Michael Joseph Darweesh) writes: >I believe that the Mac OS is written in Pascal. As a matter of fact, the >ROM procedures and functions are definately written in pascal. Some of the Mac OS routines were written in Pascal. The 64K ROM contained the compiled object code for many routines. Because of time constraints. But they were re-written in 68000 Assembly language in the 128K ROM. Thats why QuickDraw got about 60% quicker on the Mac Plus (check Tech Note 56, the old one). I think we can assume everything written since then was written in Assembly. I know for sure that Color QuickDraw was written in 68020 asm, because that is the reason the SE didn't have it. Pascal could have been compiled down to 68020 or 68000, but 68020 assembly code is a different matter. The Sound Manager was also written in 68020 assembly language. The first attempt at translating it to 68000 machines (System 6.0) was a disaster. The second attempt (6.0.2) was better. And the Apple Sound Chip was not a factor. The ASC dependent routines are contained in 'snth' resources only, not the main body of the Sound Manager. Although, I'm glad I have an ASC. They still use Pascal calling conventions (some of them). The c++ version would have to use Pascal conventions unless it breaks all programs (I wish Apple would start from scratch in an object-oriented system). Others use register calling conventions (Pascal is stack-based). Pascal compilers don't produce register based calling conventions. > >If you have a source, please enlighten me, it is possible that I'm wrong... > >Mike Darweesh >md32@andrew.cmu.edu >Carnegie Mellon +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
wb1j+@andrew.cmu.edu (William M. Bumgarner) (02/23/89)
>> I believe that the Mac OS is written in Pascal.
Very good. You are right about the old System stuff... but that isn't what
we are talking about. Apple is doing a COMPLETE REWRITE of the System--
meaning that they are rewriting everything. But this time 'round, they are
supposedly at least going to use C, and there is a version of Finder being
done in C++; what the final release versions will be is still up in the air,
but it is very, very doubtful that Apple is going to do a rewrite in Pascal.
b.bum
wb1j+@andrew.cmu.educasseres@Apple.COM (David Casseres) (02/23/89)
In article <EY0c4cy00hkj0xJJwY@andrew.cmu.edu> md32+@andrew.cmu.edu (Michael Joseph Darweesh) writes: >I believe that the Mac OS is written in Pascal. As a matter of fact, the >ROM procedures and functions are definately written in pascal. The Mac system is many pieces of code, and they are written various languages -- assembly, Pascal, C, and perhaps others. This is true of the ROM code as well as the system file. The confusion arises because the stack discipline for procedure/function calls is Pascal-based, and the documentation is predominantly Pascal- oriented. David Casseres
daw@houxs.ATT.COM (David Wolverton) (02/23/89)
In article <7068@fluke.COM>, moriarty@tc.fluke.COM (Jeff Meyer) writes: > > On another subject entirely, it's a pity that Apple decided not to call the > Mac SE/30 the Mac SEx. No reason why we can't use that name on the net. Perhaps, as in the evolution of English, if enough people begin using the name, it will "stick". Dave
billkatt@sol.engin.umich.edu (billkatt) (02/23/89)
In article <IY0io5y00UgPAM2b4a@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >>> I believe that the Mac OS is written in Pascal. > >Very good. You are right about the old System stuff... but that isn't what >we are talking about. Apple is doing a COMPLETE REWRITE of the System-- >meaning that they are rewriting everything. But this time 'round, they are >supposedly at least going to use C, and there is a version of Finder being >done in C++; what the final release versions will be is still up in the air, >but it is very, very doubtful that Apple is going to do a rewrite in Pascal. Very good. I shall now give you another lesson in being condescending. But remember... you shall never be as good as I am. The whole point of this thread is that there is no value in doing speed comparisons, because you will need all new applications to run under the new system. Therefore, you might as well compare to DOS 3.3, because it doesn't support the same overhead. I am anxiously awaiting the new rewrite, even if it breaks all, as long as it is in an object oriented format. Yes, it is doubtful that they will do a rewrite in Pascal, since the system is currently written in Assembly language, and RISC chips are optimized for C.
pkahn@inca-roca.ADS.COM (Phil Kahn) (02/23/89)
In article <41a2364a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >is in an object oriented format. Yes, it is doubtful that they will do a >rewrite in Pascal, since the system is currently written in Assembly >language, and RISC chips are optimized for C. ^^^^^^^^^^ Ah hah! The rumors of an 88000 based machine may have some substance... phil...
lsr@Apple.COM (Larry Rosenstein) (02/23/89)
In article <41a0e08a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: > >Some of the Mac OS routines were written in Pascal. The 64K ROM contained the >compiled object code for many routines. Because of time constraints. But I don't think so. Most of the Lisa libraries were written in Pascal, and some of these formed the basis of the Mac ROM routines, but I think to squeeze everything into a 64K ROM, they had to go to 100% assembler. >they were re-written in 68000 Assembly language in the 128K ROM. Thats why >QuickDraw got about 60% quicker on the Mac Plus (check Tech Note 56, the old It got faster because with 2x ROM space you could gain speed for space by unrolling loops and adding more special cases. >matter. The Sound Manager was also written in 68020 assembly language. >The first attempt at translating it to 68000 machines (System 6.0) was a >disaster. The second attempt (6.0.2) was better. And the Apple Sound Chip I think some (or all of the Sound Manager) is in C. I doubt that the problem with 6.0 was in translating to 68000 assembler. It was more likely due to the strange way sound works on old Macs. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
ra_robert@gsbacd.uchicago.edu (02/23/89)
In article <41a2364a.a590@mag.engin.umich.edu>, billkatt@sol.engin.umich.edu (billkatt) writes... [...] >because you will >need all new applications to run under the new system. Therefore, you might >as well compare to DOS 3.3, because it doesn't support the same overhead. >I am anxiously awaiting the new rewrite, even if it breaks all, as long as it >is in an object oriented format. [...] _All_ new applications? Unless they're running on a different type of CPU, why? Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
anson@spray.CalComp.COM (Ed Anson) (02/23/89)
In article <2302@cadre.dsl.PITTSBURGH.EDU> jas@cadre.dsl.PITTSBURGH.EDU (Jeffrey A. Sullivan) writes: >In article <sY0Almy00UgPMJmYsw@andrew.cmu.edu>, wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >> The Finder (and probably the System) is being rewritten in C++... >Is this true? Does this mean Apple's reworking their system into an >object-oriented architecture (yes oh yes oh please)? I'd think we'd >hear more of this. If not, why the hell use C++? The current issue of Apple direct says: "We are committed to object-oriented programming and are planning future Macintosh environments that must be programmed with object- oriented techniques." This is pretty clear. What is not absolutely clear, is whether they will thereby break all existing application software. Or will they somehow make existing software compatible? -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
sho@pur-phy (Sho Kuwamoto) (02/23/89)
In article <1975@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes:
<In article <41a2364a.a590@mag.engin.umich.edu>, billkatt@sol.engin.umich.edu (billkatt) writes...
<<[...]
<<because you will need all new applications to run under the new system.
<<[...]
<_All_ new applications? Unless they're running on a different type of CPU,
<why?
Mac programs make Toolbox calls. If the whole shebang is redone, the
Toolbox will be scrapped. I believe that the ROMs will be completely
rewritten, not just the System file. At least that's the impression
I get. People are talking Object Oriented, etc., and it's getting
harder and harder to tell truth from rumor, but I think the change is
going to be more drastic than rewriting the System file from scratch
to improve, since that won't change the functionality of the Mac much.
Of course they could call it the Mac III and have a Mac II compatibility
mode (gawd.).
-Showb1j+@andrew.cmu.edu (William M. Bumgarner) (02/24/89)
I realized my mistake to late to abort send-- the OS is written in Assembly. excuse the wasted bandwidth. b.bum wb1j+@andrew.cmu.edu
ra_robert@gsbacd.uchicago.edu (02/24/89)
In article <41a2364a.a590@mag.engin.umich.edu>, billkatt@sol.engin.umich.edu (billkatt) writes... [...] >you will >need all new applications to run under the new system. Therefore, you might >as well compare to DOS 3.3, because it doesn't support the same overhead. OS/2 is a completely different OS than MS-DOS, but it allows one to run MS-DOS applications in a "compatibility box", I think. So theoretically, you might be able to run at least one 'old' app at a time on a new Mac OS, right? And perhaps more, if Apple is clever enough. At some point you should be able to run "well-behaved" Mac apps under A/UX, so why not under a new Mac OS? Just from the hardware side, if a new machine runs on the 88k, perhaps even putting a 680x0 and and 88000 in the same box would allow you to run new and old apps (I've heard they're taking that approach -- two chips in the same box -- to create a Mac for schools which would run Mac and Apple // software; this Mac would have a 680x0 and a 6502, or whatever, in it). I do think Apple will take great care to make sure there is some way of running the programs people have. If a new Mac didn't run your current software, I think a lot of people (like businesses) would think twice about buying one. (Of course, SW companies could rewrite their current apps for the new OS and offer it as an upgrade.:->) Robert ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
casseres@Apple.COM (David Casseres) (02/24/89)
In article <752@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <41a0e08a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >> >>Some of the Mac OS routines were written in Pascal. The 64K ROM contained the >>compiled object code for many routines. Because of time constraints. But > >I don't think so. Most of the Lisa libraries were written in Pascal, and >some of these formed the basis of the Mac ROM routines, but I think to >squeeze everything into a 64K ROM, they had to go to 100% assembler. Yes indeed! I distinctly recall that the slogan of Mac system programmers at the time was "real programmers only write assembly language," and they weren't joking. >>they were re-written in 68000 Assembly language in the 128K ROM. Thats why >>QuickDraw got about 60% quicker on the Mac Plus (check Tech Note 56, the old > >It got faster because with 2x ROM space you could gain speed for space by >unrolling loops and adding more special cases. Yes indeed again. When you rewrite something in a different language and see a big performance increase, the increase is usually due to the rewriting, not the change of language (not counting interpreted languages, of course). David Casseres
billkatt@sol.engin.umich.edu (billkatt) (02/24/89)
In article <1975@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: >In article <41a2364a.a590@mag.engin.umich.edu>, billkatt@sol.engin.umich.edu (billkatt) writes... >[...] >>because you will >>need all new applications to run under the new system. Therefore, you might >>as well compare to DOS 3.3, because it doesn't support the same overhead. >>I am anxiously awaiting the new rewrite, even if it breaks all, as long as it >>is in an object oriented format. >[...] > > >_All_ new applications? Unless they're running on a different type of CPU, >why? Rewriting in an object-oriented system would require changing the all the system traps and their calling conventions. It might be possible to write a 'shell' which can be used to launch old-style applications, but at reduced speed and or functionality. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
mce@tc.fluke.COM (Brian McElhinney) (02/24/89)
billkatt writes: >William M. Bumgarner writes: >> The Finder (and probably the System) is being rewritten in C++... The speed >> increases quoted are absolutely amazing. > > Get Real. They are written in Assembly language right now. NOBODY gets a > speed up going to a higher level language. You are quoting speeds for the > new system which reqires NEW applications written in object-oriented > languages. That is comparing Apples and Oranges. Take your own advice and compare algorithms to algorithms. A slow and stupid algorithm is always going to be slow. Period. Thus a faster alogorithm is... yep, faster. For example, the Finder uses the Resource Manager to manage icons, etc, in the desktop file. That worked OK with 400K MFS floppies. But the Resource Manager was never intended to handle the thousands of resources a 100 Meg hard drive can have. AppleShare replaces this with a B-tree (K?) and is much faster. Speed has almost *nothing* to do with the language used! Most algorithms are not the ultimate, optimal, fastest, etc. Especially if the software evolved over time (and boy has the Finder evolved!). > Besides, I've used Apple's C++ and it creates a 30K application for a two > line source program (i.e. 'cout << "hey"') It has a long way to go before it > is good enough to base an operating system on. A hand saw beats a lumber mill any day, if all you want to do is cut a 2x4. Brian McElhinney mce@tc.fluke.com
dent@unocss.UUCP (Dave Caplinger) (02/24/89)
I got the following price list from a local Mac user group; I'm not sure where they got it. :-) It looks like the lineup (in "power order") not including the laptop(s) is: Plus, SE, II, SE/030, IIcx, IIx [, IIce ?] Regarding the laptops, I don't see any reason that they won't come out with the 68000 version now, and the 68030 one later... (Note: I make no claims as to the validity of these prices; and I'm posting them because the person I got them from didn't say that I couldn't...) Model List CPU RAM HD Math Floppy PMMU ---------------------------------------------------------------------- Mac Plus 1,799 68000 1 - - 800K No Mac SE 3,298 68000 1 - - 2x800K No Mac SE 20 68000 1 20 - 800K No Mac SE 2/40 4,598 68000 1 40 - 800K No Mac SE/30 4,498 68030 1 - 68882 Super Yes Mac SE/30 1/40 68030 1 40 68882 Super Yes Mac SE/30 4/80 6,798 68030 4 80 68882 Super Yes Mac II 5,896 68020 1 - 68881 800K No Mac II 68020 1 40 68881 800K No Mac II 9,245 68020 4 40 68881 800K No Mac IIcx 5,597 68030 1 - 68882 Super Yes Mac IIcx 6,822 68030 4 80 68882 Super Yes Mac IIx 7,996 68030 4 - 68882 Super Yes Mac IIx 9,745 68030 4 80 68882 Super Yes *** Note: It looks like this is not entirely acurate... I could have sworn the "vanilla" SE had a 68010 processor, not a 68000. That, and I know that the Mac II came with an 80-Meg hard drive as well. Oh well... "Apple (almost) always gets it right the second time around" -/ Dave Caplinger /------------------+----------------------------------- Microcomputer Specialist | Internet: unocc07@zeus.unl.edu "Computing and Data Communications" | UUCP: uunet!btni!unocss!dent University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 Omaha, NE 68182 | or dc3a+@andrew.cmu.edu
holland@m2.csc.ti.com (Fred Hollander) (02/24/89)
In article <41a2364a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >Very good. I shall now give you another lesson in being condescending. But >remember... you shall never be as good as I am. The whole point of this >thread is that there is no value in doing speed comparisons, because you will >need all new applications to run under the new system. Therefore, you might >as well compare to DOS 3.3, because it doesn't support the same overhead. >I am anxiously awaiting the new rewrite, even if it breaks all, as long as it >is in an object oriented format. Yes, it is doubtful that they will do a >rewrite in Pascal, since the system is currently written in Assembly >language, and RISC chips are optimized for C. This is very interesting. I don't have the strongest background in hardware architecture, but, could you please explain how a processor could be optimized for a specific high level language? Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
davis@bdmrrr.bdm.com (Arthur Davis x4675) (02/24/89)
In article <EY0c4cy00hkj0xJJwY@andrew.cmu.edu>, md32+@andrew.cmu.edu (Michael Joseph Darweesh) writes: > I believe that the Mac OS is written in Pascal. As a matter of fact, the > ROM procedures and functions are definately written in pascal. > > If you have a source, please enlighten me, it is possible that I'm wrong... > > Mike Darweesh > md32@andrew.cmu.edu > Carnegie Mellon The Macintosh ROM software was designed and written in Lisa Pascal. Once they had what they liked, they hand-tooled the stuff in 68000. In essence, Andy Hertzfeld took hundreds of K of Pascal object code and hand-optimized it in machine code. I expect that the source they work from in the System Software now is MPW Assembler rather than MPW Pascal. The 64K ROMs were rather a tight fit for high-level language compiler output.
billkatt@sol.engin.umich.edu (billkatt) (02/24/89)
In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >In article <41a2364a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >>is in an object oriented format. Yes, it is doubtful that they will do a >>rewrite in Pascal, since the system is currently written in Assembly >>language, and RISC chips are optimized for C. > >This is very interesting. I don't have the strongest background in >hardware architecture, but, could you please explain how a processor >could be optimized for a specific high level language? > >Fred Hollander Sure. Some processors (the 68000 for example) are much better suited (and some designed) for the c calling conventions. It is a mess for the called routine to remove the parameters passed to it before returning on the 68000. This isn't a problem with c. Some addressing modes (post/pre indexed increment/decrement) will get used more in c than Pascal, although they are a valuable addition to any processor. Some more blatant examples are TIs LISP chip (explorer/microexplorer) and somebodys (TIs also?) FORTH chip. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
erc@pai.UUCP (Eric Johnson) (02/24/89)
In article <70755@ti-csl.csc.ti.com>, holland@m2.csc.ti.com (Fred Hollander) writes: > > This is very interesting. I don't have the strongest background in > hardware architecture, but, could you please explain how a processor > could be optimized for a specific high level language? Certain high-level languages make certain assumptions about an underlying machine, or more usually, an underlying "virtual" machine. Most attempts to optimize a processor to a specific language seem to focus at making the processor instruction set the "virtual" machine instruction set. Some examples (I may make mistakes so please correct any inaccurate info): TI's LISP chip which focuses on the tagged data values in LISP and the use of CDR and CAR. (There are also competitors, such as the MacIvory one, but I couldn't resist mentioning TI.) Lilith Herr Docktor Professor N. Wirth's (inventor of Pascal, etc.) Modula-based workstation. The processor was aimed at the Modula language. SOAR Smalltalk On A Risc -- one of many attempts to implement Smalltalk byte-codes as a machine instruction set. Forth chip (From Novix?) A chip designed around the lanuage Forth (which seems rather strange as I always thought Forth was one of the few languages heavily optimized to the traditional stack-based architecture). Intel 80x86 I have read arguments stating that the Intel architecture was based around the concept of Pascal, especially with the four segments: Data, Code, Stack and Extra (personally, I think the Intel architecture is a crime against humanity :-). Other places to look would include the Warren Absract Machine for Prolog (I'm sure someone is working on putting this on a chip) and in object-oriented languages. Sometimes, chip-makers go the opposite route and create a new language optimized for the hardware, and Inmos did with Occam for their Transputer. Anyway, I hope this sheds some light, -Eric > > Fred Hollander > Computer Science Center > Texas Instruments, Inc. > hollander@ti.com > > The above statements are my own and not representative of Texas Instruments. -- Eric F. Johnson | Phone +1 612-894-0313 | Are we Prime Automation,Inc | UUCP: bungia!pai!erc | having 12201 Wood Lake Drive | UUCP: sun!tundra!pai!erc | fun Burnsville, MN 55337 USA | DOMAIN: erc@pai.mn.org | yet?
jackiw@cs.swarthmore.edu (Nick Jackiw) (02/25/89)
In article <752@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > In article <41a0e08a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: > > > >Some of the Mac OS routines were written in Pascal. The 64K ROM contained the > >compiled object code for many routines. Because of time constraints. But > > I don't think so. Most of the Lisa libraries were written in Pascal, and > some of these formed the basis of the Mac ROM routines, but I think to > squeeze everything into a 64K ROM, they had to go to 100% assembler. > > Larry Rosenstein, Object Specialist I beg to differ, but NOSYing around in the actual ROM code of my SE reveals dead code (not a lot of it, of course)---the sign of either a compiler at work or (I doubt it) incredibly lax quality control. Even in Quickdraw you can see compiler artifacts--check out MapPt's source sometime ... about 20% of it's dead weight. If I'm wrong, I'm wrong. No big deal. -Nick -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ " "Maldoror!"
stuartb@microsoft.UUCP (Stuart Burden) (02/25/89)
In article <1998@pur-phy> sho@newton.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: | Mac programs make Toolbox calls. If the whole shebang is redone, the | Toolbox will be scrapped. I believe that the ROMs will be completely | rewritten, not just the System file. At least that's the impression | I get. People are talking Object Oriented, etc., and it's getting | harder and harder to tell truth from rumor, but I think the change is | going to be more drastic than rewriting the System file from scratch | to improve, since that won't change the functionality of the Mac much. | Of course they could call it the Mac III and have a Mac II compatibility | mode (gawd.). I wonder how much of a deciding factor this might have been, in putting the new ROMs on removable cards..(ala MacIIx etc)? First thing I thought of when I saw them, was "well that ought to be easy to upgrade". | -Sho Stu. __Paths to my door:_______________________ microsoft!stuartb@beaver.cs.washington.edu - Usual disclaimer, that all microsoft!stuartb@uw-beaver.arpa - the above is pure fantasy microsoft!stuartb@uunet.UU.NET - and Microsoft only [DE01HB]stuartb@DASNET# {from AppleLink} - gave me the Mountain Dew stuartb@microsoft.uucp {well connected} - to dream it all in a D2012 {@applelink.apple.com - shared acct} - caffeine haze :-) __________________________________________________________________________
dorourke@polyslo.CalPoly.EDU (Sir Hoyt) (02/25/89)
In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >This is very interesting. I don't have the strongest background in >hardware architecture, but, could you please explain how a processor >could be optimized for a specific high level language? I don't have the strongest background either, and I not the original poster that you asked to respond. But I think you'll find my posting interesting none the less. If you want to see a good example of a processor being optimized for a particular language Unisys {really Burroghs} A-Series arch. is optimized for Algol. The way they do this is by providing Machine language instructions that implement whole/parts of constructs present in the target high level language. For example Algol 60 does parameters with call by name, so they have some assembly language instructions that make this process rather easy to implement for a compiler. Also the 68000 {sort of a small PDP-11 if memory serves} is not a bad processor for C {since C was originally done on a PDP-11 again if memory serves} because it has all sorts of pre/post increment/decrement instructions, along with stack build/tear-down instructs that make a block structured langage like c/pascal easier to implement. I hope this helps. But if you look at processor design you can sometimes see what language it was originally designed for by the instruction set it has. -- David M. O'Rourke dorourke@polyslo.calpoly.edu It's only 1's & 0's, so how difficult can Computer Science be? ===============================================================================
sagen@nucthy.physics.orst.edu (Milt Sagen) (02/25/89)
In article <7109@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >billkatt writes: > >A hand saw beats a lumber mill any day, if all you want to do is cut a 2x4. > Not if you are starting with a 200 ft. Douglas fir. :-) Are there no more trees in Washington? ;-(^) <- tongue in cheek. Milt Sagen Internet: sagen@nucthy.physics.orst.edu Department of Physics Oregon State University Corvallis, OR 97331 Tele: (503) 754-4631
wetter@cit-vax.Caltech.Edu (Pierce T. Wetter) (02/26/89)
> Get Real. They are written in Assembly language right now. NOBODY gets a > speed up going to a higher level language. You are quoting speeds for the > new system which reqires NEW applications written in object-oriented languages. No they aren't. Or at least not 100% of them. Large parts of the Finder and system are written in an HLL, though some parts are written in assembly. On another note, at the very least, apple will have to rewrite the toolbox in order to make it reentrant if they wish to develop true preemptive multitasking. Pierce -- ____________________________________________________________________________ You can flame or laud me at: wetter@tybalt.caltech.edu or wetter@csvax.caltech.edu or pwetter@caltech.bitnet (There would be a witty saying here, but my signature has to be < 4lines)
wetter@cit-vax.Caltech.Edu (Pierce T. Wetter) (02/26/89)
> > I wonder how much of a deciding factor this might have been, in putting the > new ROMs on removable cards..(ala MacIIx etc)? First thing I thought of > when I saw them, was "well that ought to be easy to upgrade". > That's what I thought too, until I realized that the roms have always been socketed. The only advantage of putting the ROMS on cards is that you can easily make them bigger. 256K ->512K etc. I seriously doubt that Apple will ever come out with anything called a MacIII if only for historical reasons. Pierce -- ____________________________________________________________________________ You can flame or laud me at: wetter@tybalt.caltech.edu or wetter@csvax.caltech.edu or pwetter@caltech.bitnet (There would be a witty saying here, but my signature has to be < 4lines)
holland@m2.csc.ti.com (Fred Hollander) (02/27/89)
In article <409@pai.UUCP> erc@pai.UUCP (Eric Johnson) writes: > >Certain high-level languages make certain assumptions about an underlying >machine, or more usually, an underlying "virtual" machine. Most attempts >to optimize a processor to a specific language seem to focus at making >the processor instruction set the "virtual" machine instruction set. >Some examples (I may make mistakes so please correct any inaccurate info): [ lot's of good info on hardware specifically designed for special purpose langauges (Lisp, Forth, SmallTalk,...) deleted ] >Anyway, I hope this sheds some light, >-Eric Well, I'm a little embarassed because I didn't even consider things like Lisp machines. What caught my attention was the poster's claim that RISC was optimized for "C" [as opposed to Pascal]. The differences between the hardware requirements for these two language were less apparent. Thanks for such an informative reply. Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
dce@stan.UUCP (David Elliott) (02/27/89)
In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >In article <41a2364a.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >>is in an object oriented format. Yes, it is doubtful that they will do a >>rewrite in Pascal, since the system is currently written in Assembly >>language, and RISC chips are optimized for C. > >This is very interesting. I don't have the strongest background in >hardware architecture, but, could you please explain how a processor >could be optimized for a specific high level language? Well, the statement isn't entirely true. There exist RISC chips that are optimized for C, but RISC doesn't imply C optimization. The MIPS chip, for example, is more optimized for Unix in general than C. After all, you don't need virtual memory just for C, and the R[23]000 have a TLB just for that reason. Anyway, to answer the question, RISC means "reduced instruction set computer", and also tends to imply a reduced number of addressing modes as well. Since you are limited in instructions and addressing modes, you need to pick those which are beneficial to your application. Since C compilers don't have a "string" primitive, it is unlikely that a C compiler would be able to use string instructions, so you might leave these out. You can also examine a large set of "typical" programs and see how many registers you are likely to need. The architects and designers take this information and use it to efficiently utilize the chip area. In the MIPS architecture, the goal was to keep the pipeline from stalling, so instructions were implemented so that they could be executed in a single cycle (note: this doesn't mean that instructions take only one cycle to execute). Also, the extra chip area was used to make the multiplier faster and to implement TLB registers for virtual memory. In other words, you optimize for the final application by putting together a group of experts. In the case of a Unix processor, you get C compiler and Unix kernel experts. If you were working on an imbedded controller chip, you would get people who understand devices and device drivers. -- David Elliott ...!pyramid!boulder!stan!dce "Splish splash, I was rakin' in the cash" -- Eno
kurtzman@pollux.usc.edu (Stephen Kurtzman) (02/28/89)
In article <8513@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: > I hope this helps. But if you look at processor design you can sometimes >see what language it was originally designed for by the instruction set >it has. Conversely, if you look at a language you can sometimes see for which processor it was designed. As noted by others, c was originally designed for the PDP-11. Because the PDP-11 has pre-decrement indirect, and post-increment indirect addressing modes, c has ++ and -- constructs to take advantage of the PDP-11 architecture. Likewise, the car and cdr of LISP have their analogues in the architecture of the machine on which LISP was first implemented. There are likely other examples, but I'll leave that to the language specialists.
carlson@hpindda.HP.COM (Bob Carlson) (02/28/89)
/ hpindda:comp.sys.mac / dorourke@polyslo.CalPoly.EDU (Sir Hoyt) / 10:16 am Feb 24, 1989 / In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >>This is very interesting. I don't have the strongest background in >>hardware architecture, but, could you please explain how a processor >>could be optimized for a specific high level language? > If you want to see a good example of a processor being optimized for >a particular language Unisys {really Burroghs} A-Series arch. is >optimized for Algol. The way they do this is by providing Machine >language instructions that implement whole/parts of constructs present >in the target high level language. Burroughs loved this and carried to extremes. The Burroughs medium systems were optimized for COBOL. Most COBOL lines translated into a single line of code. Some skeletons lurk in this closet. Rumour has it that Knuth designed some of the more esoteric instructions under a consulting contract. Also, an architect (Mike Mahon) on this system eventually became the chief architect of the HPPA RISC-like system. Quite a switch going from COBOL instructions to RISC. Burrough's small systems, the 1700, had dynamicly changable control store. Each running program could be running a different instruction set! Cute idea, but it barked and had to be housebroken. Cheers, Bob
peter@versatc.UUCP (Peter Tapscott) (02/28/89)
In article <41aa5eaa.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: >In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >>Could you please explain how a processor >>could be optimized for a specific high level language? > >Sure. Some processors (the 68000 for example) are much better suited (and >some designed) for the c calling conventions. It is also possible to write the c-code to produce optimum execution speed. For example, the following four lines of code execute 4X faster than the two lines using a FOR loop: Fast While Loop: i = char_count; while(i--) destn_buffer[i] = *(source_buffer + i); *destn_buffer = *source_buffer; /* get the zeroth element */. Slow For Loop: for (i = 0; i <= char_count; i++) destn_buffer[i] = *(source_buffer + i); This is because the while loop makes use of the DBNE (decrement and branch if not equal to zero) instruction of the 68020, so the disassembled code shows fewer, faster instructions. This disproves the popular misconception that writing the c-code in the fewest lines is the same as optimizing the code. In many cases it is not faster and minimizes the readability. -- |----------------------------------------------------------------------| | Peter Tapscott {pyramid|ames|sun|vsi1|leadsv}!versatc!peter | | Versatec, 2805 Bowers Avenue, Santa Clara, Calif 95051 (408)982-4235 | |----------------------------------------------------------------------|
rcb@cccvs1.ncsu.edu (Randy Buckland) (02/28/89)
For general amusement, try looking at the generated code for the following
in LightSpeed C 3.0
strcpy (out, in)
char *out, *in;
{
while (*in)
*out++ = *in++;
}
as opposed to
strcpy (out, in)
char *out, *in;
{
while (*in)
{
*out = *in;
out++;
in++;
}
}
The first looks like it should be more efficient and would be on some machines
with the right compiler, However in LightSpeed C, the second is drastically
more efficient due to the order the operations are carried out in. It gets
even better if the pointers are optimised into registers or explicitly copied
into registers.
Randy Buckland
rcb@ncsuvx.ncsu.edutim@crackle.amd.com (Tim Olson) (03/01/89)
In article <15564@oberon.USC.EDU> kurtzman@pollux.usc.edu (Stephen Kurtzman) writes: | In article <8513@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: | > I hope this helps. But if you look at processor design you can sometimes | >see what language it was originally designed for by the instruction set | >it has. | | Conversely, if you look at a language you can sometimes see for which processor | it was designed. As noted by others, c was originally designed for the PDP-11. | Because the PDP-11 has pre-decrement indirect, and post-increment indirect | addressing modes, c has ++ and -- constructs to take advantage of the PDP-11 | architecture. I believe that the pre- and post- inc/dec operators were already present in BCPL and B, and that is where they came from. However, the implicit conversion from float to double in (K&R) C for all floating-point operations was due to the PDP-11, on which it was difficult to switch between single and double-precision modes. | Likewise, the car and cdr of LISP have their analogues in the | architecture of the machine on which LISP was first implemented. There are | likely other examples, but I'll leave that to the language specialists. Not really -- CAR stands for "Contents of Address Register" and CDR stands for "Contents of Decrement Register" on the IBM machine that the first LISP interpreter was written on, and definitely are not analogues to the car and cdr operations. Lisp machines came much later. -- Tim Olson Advanced Micro Devices (tim@crackle.amd.com)
billkatt@sol.engin.umich.edu (billkatt) (03/06/89)
In article <9768@cit-vax.Caltech.Edu> wetter@cit-vax.Caltech.Edu (Pierce T. Wetter) writes: >> Get Real. They are written in Assembly language right now. NOBODY gets a >> speed up going to a higher level language. You are quoting speeds for the >> new system which reqires NEW applications written in object-oriented languages. Let me correct myself. I give the mistaken impression that the system/finder was written in Assembly language. I only mean to say that the Toolbox calls were written in Assembly language. -Steve