kim@amdahl.amdahl.com (Kim DeVaughn) (10/05/87)
[ "Send lawyers, guns, and AT&T ..." ] Pete Jordan posted this interesting tidbit on our internal Amiga conference: > UNIX System V on the A2000 > > On the FAUG board, Thad [Floran <sp?>] said he recently talked to Rick > Sterling, Sr QA test engineer at CBM. Thad learned this: > > The CBM MMU for the A2000 (with 68020) is way beyond first silicon; > is fully operational, UNIX System V now runs on the A2000 using the > 68020 and the CBM MMU. A demo will be given at Comdex this fall, and > UNIX will be available for sale 1st qtr 1988. The system will default > to the UNIX System V and you will have to lean on the right mouse button > in order to boot up as Amigados. > > Rick also said there were some other extremely exciting things coming > from CBM for the Amiga, but he was not at liberty to divulge them. Now, what I wanna know is ... what do I have to do to get BSD 4.x instead of SysV, and it's braindamaged 14-character filename limit? Perry, how about with *your* 020 board ...? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
page@ulowell.cs.ulowell.edu (Bob Page) (10/06/87)
kim@amdahl.amdahl.com (Kim DeVaughn) wrote: >Pete Jordan posted this interesting tidbit > UNIX will be available for sale 1st qtr 1988. The system will default > to the UNIX System V and you will have to lean on the right mouse button > in order to boot up as Amigados. Hmmm.. I heard (from a fairly reliable source) that the Amiga's UNIX package will run as an Amiga task/library/window, like MS-DOS does on Janus. I also heard (from a different fairly reliable source) that the Amiga's UNIX will not use ANY of the Amiga Kernel, and will only take advantage of the co-processors to do fast text ... no windows, no graphics, no sound, etc. Essentially UNIX on a 68020, that happens to have the word AMIGA stamped on the cover of the box. I hope it's the first case, but we'll see. Both 'informants' were people-who-should-know within CBM. > Rick also said there were some other extremely exciting things coming > from CBM for the Amiga, but he was not at liberty to divulge them. Want some wild speculation? What does the Amiga need right now? - Hard disk boot support (KS 1.2.1 ?) - A faster file system (KS 1.2.1 ?) - A scan-doubler (in the works from third parties, CBM too?) - 1MB chip mem (add on to A500 and x2000 in the near future) - Streaming tape backup, SCSI and/or ST506 - Higher resolution (like 1024x800, being worked on by 3rd parties) - A laser printer (CBM announced plans for it a long time ago) - An NTSC digitizer (Unless they're depending on 3rd parties) - Native 68020 support for all models - Faster CPU/Coprocessor/Memory speeds - Other-computer emulators (Mac, ST) - More 'name' software titles ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
wilkes@beatnix.UUCP (John Wilkes) (10/06/87)
In article <15626@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: > >Pete Jordan posted this interesting tidbit > >> UNIX System V on the A2000 >> >> The CBM MMU for the A2000 (with 68020) is way beyond first silicon; >> is fully operational, UNIX System V now runs on the A2000 using the >> 68020 and the CBM MMU. A demo will be given at Comdex this fall, and >> UNIX will be available for sale 1st qtr 1988. The system will default >> to the UNIX System V and you will have to lean on the right mouse button >> in order to boot up as Amigados. Gee, does this mean I should return that 3B1 I just bought at the AT&T fire sale? 67M hard disk, 2M ram, UNIX sysV, etc., for $2K... Nah, I'll keep the stuff. After all, ``1st qtr 1988'' may not come around for another 12 to 18 months (-: remember the Sidecar? :-) >Now, what I wanna know is ... what do I have to do to get BSD 4.x instead >of SysV, and it's braindamaged 14-character filename limit? Me, too! It's not available for the AT&T thingie, I've already checked. Are you listening, C=?? 4.2 > V !! don't you just love the new inews? -- John Wilkes --- UUCP: {ucbvax,ihnp4}!sun!elxsi!wilkes ARPA: elxsi!wilkes@lll-tis.ARPA USPS: ELXSI Ltd., 2334 Lundy Pl., San Jose, CA 95131 BELL: (408) 942-0900
klm@munsell.UUCP (Kevin (my watch has a touch screen) McBride) (10/07/87)
In article <15626@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >> >> The CBM MMU for the A2000 (with 68020) is way beyond first silicon; >> is fully operational, UNIX System V now runs on the A2000 using the ...[stuff deleted] >> Rick also said there were some other extremely exciting things coming >> from CBM for the Amiga, but he was not at liberty to divulge them. > >Now, what I wanna know is ... what do I have to do to get BSD 4.x instead >of SysV, and it's braindamaged 14-character filename limit? Perry, how >about with *your* 020 board ...? > >/kim Now, what I wanna know is ... IS ANYBODY EVER GOING TO KNOW THIS BESIDES THE FAITHFUL (MEANING WE HACKERS)??? If this is true, it would be a beautiful way for Commodore to get big time penetration into the Bu$ine$$ Market. Whether the hardware is going to be a reality or not is not my point. My point is that *if* this system is going to exist, YOU HAD BETTER DAMN WELL ADVERTISE THE S--T OUT OF IT, COMMODORE!!! BTW, sign me up for one of these. I'd love to shove it in the faces of a few (Sun) Unix snobs here who think my Amy is a mere toy. Also, can anybody tell me if it will be possible to run Xenix on the PC side of the A2000 when the '286 Bridge Board comes out, or is the software on the Amiga side that controls this show MS-DOS specific? Wouldn't that be nice, having 2 multi-tasking operating systems running on 1 machine? -- Kevin McBride | "Is that a real | harvard -\ I/O Software Group | poncho, or is that | ll-xn ---adelie----> munsell!klm Eikonix - A Kodak Co. | a Sears poncho?" | decvax -v talcott -v | Billerica, MA | - Frank Zappa | allegra ------------encore
blgardne@esunix.UUCP (Blaine Gardner) (10/08/87)
in article <1801@ulowell.cs.ulowell.edu>, page@ulowell.cs.ulowell.edu (Bob Page) says: > > Want some wild speculation? What does the Amiga need right now? > > - Higher resolution (like 1024x800, being worked on by 3rd parties) Everyone _says_ they want workstation resolution, but how many people are really willing to pay $1500 - $3000 for a monitor that will support it? Having 1024x800 would be great, but that kind of money for a monitor is out of the question for home use. Having a monitor that costs as much or more that the computer will be bit too much for most people to swallow. -- Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 UUCP Address: {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!blgardne {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne "I don't see no points on your ears boy, but you sound like a Vulcan!"
peter@sugar.UUCP (Peter da Silva) (10/09/87)
> Pete Jordan posted this interesting tidbit on our internal Amiga > conference: > > > The CBM MMU for the A2000 (with 68020) is way beyond first silicon; > > is fully operational, UNIX System V now runs on the A2000 using the > > 68020 and the CBM MMU. My questions are more of a "user interface" nature. 1. Does this UNIX support windows (using something like the SysV support for the Blit terminal, perhaps), or is it like the Mac/Lisa UNIX with a purely text interface? 2. If not, does it at least provide ROM KERNEL access for user programs, the way Apple's Mac II UNIX is supposed to provide access to Quickdraw? 3. How much RAM does it require? 4. Does it require either the video slot or 1 MEG of CHIP. i.e., could it run in a 2000-and-1 in a 1000? I don't suppose I'll get answers right now, but it can't hurt to ask. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/15/87)
In article <520@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: >Everyone _says_ they want workstation resolution, but how many people >are really willing to pay $1500 - $3000 for a monitor that will support >it? Having 1024x800 would be great, but that kind of money for a monitor >is out of the question for home use. Having a monitor that costs as much >or more that the computer will be bit too much for most people to >swallow. Excellent point! Yes folks please check out the price of monitors before you say "gee why can't it do 1K x 1K?". With the onslaught of workstations the price of bare (no case, no power supply, just the tube electronics) monochrome 1K x 1K monitors has come down to under $1000 in OEM quantities color ones are still in the clouds. Something realistic to desire would be something one of these multiscan type monitors can display (800 X 600) and keep the monitor price around $750 list. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
ralph@ncrcae.Columbia.NCR.COM (Ralph Hightower) (10/16/87)
I do not really care if there were a UNIX box that had Hi-Res graphics. What I want is an affordable UNIX box that has a spreadsheet, data base program, word processor, and full UNIX. Graphics would be purty (pretty intentionally mispelled), but if Amiga-DOS could co-exist on the hard disk, then I could switch from Amiga-DOS to UNIX as I needed. One other requirement for an affordable UNIX box: the hardware is not a IBM PC or PS/2 design (or clone)! Affordable IBM PCs is an oxymoron. ralph@ncrcae.Columbia.NCR.COM
mike@ames.arpa (Mike Smithwick) (10/18/87)
[Hummm BABY! in '88 ] >>is out of the question for home use. Having a monitor that costs as much >>or more that the computer will be bit too much for most people to >>swallow. > >Excellent point! Yes folks please check out the price of monitors before >you say "gee why can't it do 1K x 1K?". With the onslaught of workstations >the price of bare (no case, no power supply, just the tube electronics) >monochrome 1K x 1K monitors has come down to under $1000 in OEM quantities >color ones are still in the clouds. Something realistic to desire would be >something one of these multiscan type monitors can display (800 X 600) and >keep the monitor price around $750 list. > >--Chuck McManis The first Macintrash II demo I saw had a really nice 1000x1000, 19" color monitor propped up next to the machine. "Oh, oh" thought I, worried that my little Amy might've finally met it's match. Until I had the presence of mind to ask the salesguy how much that really nice 1000x1000, 19", COLOR box would set a person back. "Four Grand". Need I say any more?? mike, the guy not in the cape -- *** mike (powered by M&Ms) smithwick *** "ever felt like life was a game, and someone gave you the wrong instruction book?" [discalimer : nope, I don't work for NASA, I take full blame for my ideas]
peter@dalcsug.UUCP (Peter Philip) (10/18/87)
In article <520@esunix.UUCP> you write: >in article <1801@ulowell.cs.ulowell.edu>, page@ulowell.cs.ulowell.edu (Bob Page) says: >> >> Want some wild speculation? What does the Amiga need right now? >> >> - Higher resolution (like 1024x800, being worked on by 3rd parties) > >Everyone _says_ they want workstation resolution, but how many people >are really willing to pay $1500 - $3000 for a monitor that will support I agree totally, home users do not need that kind of resolution, it would be nice, but the present pixel resolution is fine, however we could ALL use MORE COLORS which I hope would be offered by new graphics boards. This would improve graphics drastically without having to buy a new monitor. (new software yes, but new monitor, no) >it? Having 1024x800 would be great, but that kind of money for a monitor >is out of the question for home use. Having a monitor that costs as much >or more that the computer will be bit too much for most people to >swallow. BUT, this capability would open up a whole new market for the Amiga, just think of an A2000 with a 16 MHz 68020/68881 a fast 80 Mb hard drive and a 1K x 1K graphics board -- the applications are endless and the price would be great! Just one request to anyone working on such a board, make it NTSC compatible!! I would definitely buy the above configuration if it was available, to use for graphics and video production, but if it wasn't NTSC (or adaptable) I would be stickin' to my faithful A1000. >Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 Peter Philip
king@dciem.UUCP (Stephen King) (10/20/87)
In article <162@dalcsug.UUCP> peter@dalcsug.UUCP (Peter Philip) writes: >I agree totally, home users do not need that kind of resolution, it would >be nice, but the present pixel resolution is fine, however we could ALL >use MORE COLORS which I hope would be offered by new graphics boards. This >would improve graphics drastically without having to buy a new monitor. Then you would have non-coprocessor graphics memory. Goodbye sprites, bobs, animation & hardware drawing functions. >a 1K x 1K graphics board -- the applications are endless and the price >would be great! Just one request to anyone working on such a board, >make it NTSC compatible!! I would definitely buy the above configuration How would you squeeze 1024 lines into a ~480 line screen? Scan convertors which do this sort of thing for high-end workstations cost many kilobucks. Probably as much as a 1024 line monitor. There is no easy way to make 1024x1024 resolution NTSC compatible. NONE. ZILCH. Furthermore, add-on graphics hardware will require custom drivers. We run the risk of falling into an IBM like CGA, PGA, EGA chasm which the Amiga avoids because ALL Amigas have the same graphics hardware (this is one reason I bought an Amiga). You can, of course, put a bridge card in an A2000 and use a PC graphics card with the high resolution, and run PC software for it. Then you have the best of both worlds, but you will have to pay for it! ...sjk -- * Defence & Civil Institute * ...!utzoo!dciem!king * of Environmental Medicine * Stephen J King - Simulation & Training Group - (416) 635-2149
jdg@elmgate.UUCP (Jeff Gortatowsky) (10/21/87)
In article <31021@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <520@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: >>Everyone _says_ they want workstation resolution, but how many people >>are really willing to pay $1500 - $3000 for a monitor that will support > >Excellent point! Yes folks please check out the price of monitors before >you say "gee why can't it do 1K x 1K?". With the onslaught of workstations >the price of bare (no case, no power supply, just the tube electronics) >monochrome 1K x 1K monitors has come down to under $1000 in OEM quantities >color ones are still in the clouds. Something realistic to desire would be >something one of these multiscan type monitors can display (800 X 600) and >keep the monitor price around $750 list. > >--Chuck McManis Excellent point is right! Further... anyone considered how much it costs to *repair* a 1024x1024 monitor that starts to fade (Ring bells Chuck?? 8^) )? Or starts to tear at the edges, or whose yoke is out of alignment, or edge focus is off (by a mile!). In my *LIMITED* experiance (about 200+ systems) with workstations that have 1024x1024 (or 1192x900 ;^> ) displays, you can forget it for the small business/home market. Believe me, I've sent plenty back to be repaired. Unless CBM starts to offer maintenance contracts you don't *really* want that type of monitor...... yet. Seriously, I'm not picking on Chuck (or SMI), but high resolution monitors are expensive to repair as well as to buy. Just like race cars... speed costs money, how fast do you want to go? Further, just like high performance cars, they tend to break more often and cost more to repair. Chunk's suggestions for 800x600 seem much more reasonable (I like powers of 2 so I'd like 768x512). -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?
WITHERS%RCN.BITNET@mitvma.mit.edu (GAW) (04/14/88)
Hello All, I am new to the world of Amiga and have noticed reference to Amiga Unix. The reference was more to the fact or suposition that AmigaDOS would run as a task under Amiga Unix but my query is simpler than that. What is Amiga Unix? I am farmilar with the Unix operating system, System V, Bsd 4.2, and even DOMIAN/IX (the Apollo version of Unix). Is a Unix available on the Amiga? If so, is it full featured and where can it be obtained? I would appreciate any elightenment here. Thanx. George Withers, WITHERS@RCN.BITNET Fitchburg State College, Fitchburg MA 01420 [Computer Science Department] "We are the music makers, and we are the dreamers of dreams." - W. Wonka ============================================================================
darin@laic.UUCP (Darin Johnson) (04/19/88)
Has anyone bothered to think about writing a non-VM unix for the Amiga?
Buying a 68020/851 card for the 2000 just to run unix seems like a waste
to me. Also, if it indeed requires 100Meg disk (and can't be pruned down
to say... 10Meg) it will indeed be out of my league (I have no problem
leaving find/uucp/vi/uncompress/etc. on floppy).
I don't think (could be wrong) that Xenix requires any sort of special
hardware (or gobs of file space). Therefore, why is Commodore writing
a version that will be so expensive to use? It would be real smart of
them to write a version that will work with or without the
extra card.
And again, I my just wait for someone to port MINIX and then I'll be halfway
there...
--
Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin)
(...ucbvax!sun!sunncal!leadsv!laic!darin)
All aboard the DOOMED express!daveh@cbmvax.UUCP (Dave Haynie) (04/21/88)
in article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) says: > Has anyone bothered to think about writing a non-VM unix for the Amiga? > Buying a 68020/851 card for the 2000 just to run unix seems like a waste > to me. Also, if it indeed requires 100Meg disk (and can't be pruned down > to say... 10Meg) it will indeed be out of my league (I have no problem > leaving find/uucp/vi/uncompress/etc. on floppy). You don't absolutely have to have virtual memory in a UNIX system, though you'll probably find, given the typical size of the more useful UNIX applications, that lots of stuff won't run without it, unless you've got gobs of real memory. What you must have, however, for a modern UNIX, is some form of memory relocation, paging, whatever you'd like to call it. This gives you things like fork() which don't exist in the AmigaOS, and basically require that each process run at the same address. While the 80286 machines that Xenix run on are pretty brain damaged from an architectural point of view, their segmentation scheme works as well as paging to make each process appear to run at the same location in memory. So you can just drop Xenix into an AT[Clone] and go. The plain old 68000 doesn't support anything like that. Which leaves you with three choices: [1] Don't worry about paging. Or the fork() function. Thus also not worrying about running any standard UNIX OS. [2] Don't page in hardware, which leaves your task swap overhead as probably the largest task in your OS, and make the not- overly-efficient-UNIX-OS such a pig as to make it useless. [3] Add some expensive hardware, like an MMU for paging, VM, and protection. Also add a faster CPU that'll handle VM as well and give you the power to run UNIX at an acceptable speed too. > I don't think (could be wrong) that Xenix requires any sort of special > hardware (or gobs of file space). Therefore, why is Commodore writing > a version that will be so expensive to use? It would be real smart of > them to write a version that will work with or without the > extra card. The UNIX port for the Amiga is a real, AT&T System V.3, same thing that runs on VAXen around the world. Xenix is something rather strange; I'm not sure that kludge is the right word, but the fact that it's running on AT[Clones] leads me to believe that kludge may not be the wrong word. What I do know is that any real UNIX OS on a 68020 system is going to be inherently better than any UNIX OS on an AT[Clone] system, and especially so if you're used to VAXen or Suns rather than PDP-11s (well, some folks still use PDP-11s). > And again, I my just wait for someone to port MINIX and then I'll be halfway > there... Naa. What's Minix, something like Version 7. With no memory protection. So what you get can be mathematically calculated as: Version 7 ----------------------------- = 28% of the way there. 22 (V is the 22nd letter) + 3 And that doesn't even take into account the memory protection. > Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin) > (...ucbvax!sun!sunncal!leadsv!laic!darin) > All aboard the DOOMED express! -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
dca@kesmai.COM (David C. Albrecht) (04/21/88)
In article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) writes: > Has anyone bothered to think about writing a non-VM unix for the Amiga? > Buying a 68020/851 card for the 2000 just to run unix seems like a waste > to me. Also, if it indeed requires 100Meg disk (and can't be pruned down > to say... 10Meg) it will indeed be out of my league (I have no problem > leaving find/uucp/vi/uncompress/etc. on floppy). > > I don't think (could be wrong) that Xenix requires any sort of special > hardware (or gobs of file space). Therefore, why is Commodore writing > a version that will be so expensive to use? It would be real smart of > them to write a version that will work with or without the > extra card. > -- Well, check out your latest Amazing Computing wherein you find an ad for AMIX a unix-like derivative which as far as I can tell runs on a stock Amiga. Personally, I think it was only sensible of Commodore to aim their unix at the CBM 68020 board market. It has very little to do with VM it has much more to do with ability of a MMU to make each process see its memory space as sequential and allocate memory from a block in that space while the actual location of that block in real memory is irrelevant. It makes 'fork' ever so much easier and efficient. It also pretty much eliminates the problem of one task bringing down the whole machine and viruses writing wherever they want on disk (unless you are on root). If they are really interested in the workstation market, a non-mmu version just wouldn't cut it. I expect that mmu and non-mmu versions would be quite different beasts and I for one would not want to have to simulate 32 bit arithmetic (or make procedure calls) just so it could support the 68000. As a separate product maybe (if they thought it worth the effort) as a unified product, I don't think so. David Albrecht
doug@eris (Doug Merritt) (04/21/88)
In article <3663@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >While the 80286 machines that Xenix run on are pretty brain damaged from ^^^^^^^^^^^^^ (definitely agree!) >an architectural point of view, their segmentation scheme works as well >as paging to make each process appear to run at the same location in >memory. So you can just drop Xenix into an AT[Clone] and go. The plain >old 68000 doesn't support anything like that. That's not quite accurate, and is in fact quite unfair to the 68000 family, which has address modes that are more general than the 80x86 family. The 68000 can be programmed to use a pure segmentation scheme, using "register indirect with offset" and "indexed register indirect with offset". For that matter, you can create 68K code that is purely relocatable. The difference that you're thinking of is that the 286 has a simple MMU built into it to support their crumby segmentation scheme, while the 8086 had none. The result *will* run Xenix, but due to the addition of MMU hardware, not from some advantage to segmentation. Quite the contrary! Having worked *extensively* with Xenix on the 286, and with Unix on a 68000 (with a custom MMU), I can tell you definitively that the 68000 is a *much* more pleasant architecture. As an example, try porting any Unix program that has arrays larger than 64K. It's trivial on a 68K, but requires a rewrite from the ground up, in general, for the 286. And yes, this did come up often...it seems that once people start writing for nonsegmented architechtures (e.g. VAX), they start assuming that large arrays are ok. How silly. Everyone knows that 64K is a reasonable absolute limit on the size of data structures! :-) The 286 is newer than the 68000; a fair comparison is against the 68010 with the 68851 or something. In which case Unix works better on the 68010 than Xenix on the 286. By far. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
peter@sugar.UUCP (Peter da Silva) (04/22/88)
Now this article got corrupted, but apparently not to badly... In article <3663@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) says: > > Has anyone bothered to think about writing a non-VM unix for the Amiga? > > Buying a 68020/851 card... seems like a waste... > You don't absolutely have to have virtual memory in a UNIX system, though > ... that lots of stuff won't run without it... This isn't really an answer to the guy's question. To begin with it implies that UNIX is a hog. System V might be a hog (though it's way better than some of the proprietary operating systems certain well-known companies are developing), but UNIX <> System V. > What you must have, however, for a modern UNIX, is some form of memory > relocation, paging, whatever you'd like to call it. This gives you things What you need, however, for *any* UNIX (modern or not) is memory management. This is the point you should have started with... There is absolutely no need for a super huge hard disk, or a 68020, but you definitely need a '51. [ drivel from an sf-lovers discussion about Star Trek and Frederick Brown ] > The UNIX port for the Amiga is a real, AT&T System V.3, same thing that > runs on VAXen around the world. Last I checked the megaUNIX of choice for the Vax was BSD. > Xenix is something rather strange; I'm > not sure that kludge is the right word, but the fact that it's running on > AT[Clones] leads me to believe that kludge may not be the wrong word. System V runs fine on an AT. No, it's not as nice as a 68020, but I'm not sure that an 80386 system wouldn't have even odds of taking on a 68020 and not embarrasing itself. Anyway, just because it runs on an AT doesn't qualify Xenix as a kludge. The fact that it's Version 7 with some System III mods dolled up to look like System V, however, does. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
DMasterson@cup.portal.com (04/23/88)
In message <9031@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: >In article <3663@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>While the 80286 machines that Xenix run on are pretty brain damaged from > ^^^^^^^^^^^^^ >(definitely agree!) > >>an architectural point of view, their segmentation scheme works as well >>as paging to make each process appear to run at the same location in >>memory. So you can just drop Xenix into an AT[Clone] and go. The plain >>old 68000 doesn't support anything like that. > >Quite the contrary! Having worked *extensively* with Xenix on the 286, >and with Unix on a 68000 (with a custom MMU), I can tell you definitively >that the 68000 is a *much* more pleasant architecture. As an example, >try porting any Unix program that has arrays larger than 64K. It's >trivial on a 68K, but requires a rewrite from the ground up, in general, >for the 286. > [The line eater was here.] > >The 286 is newer than the 68000; a fair comparison is against the >68010 with the 68851 or something. In which case Unix works better >on the 68010 than Xenix on the 286. By far. > I just wanted to add a couple of things to this. I have worked with a version of Unix (Sys III) that ran on IBM PC/XTs. It was ssslllooowww (no doubt about that), but it did work (yes it was a small model architecture). I also remember seeing advertisements for Unix running on 68K systems. The point being that Unix can be made to fit in smaller architectures (they don't call it portable for nothing). Why would you want to put it in these smaller architectures considering everything you would give up?? This is the problem with Commodore's and all Unix vendor's philosophies. They are ignoring the home market for Unix!! A large number of people work on Unix development at work and often want to do some development at home (or at least test out ideas). In the home market, a system at $3K and up doesn't make sense just to run Unix, but a $1.5K to $2K system could. If Unix is to make the impact that MS-DOS did in the PC market, it has to be made affordable enough that people can take it home!!! Once people begin taking it home to use, support for them and products for the home market will follow. Perhaps Minix is the way to go?!? Well, I guess I'll have to break down and use it on the PC side of my A2000. <*sigh*> (floating thought, consider the sale you just lost ,:-( > Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) > or ucbvax!unisoft!certes!doug > or sun.com!cup.portal.com!doug-merritt David Masterson DMasterson@cup.portal.com
wtm@neoucom.UUCP (Bill Mayhew) (04/24/88)
I suppose if you really wanted it, you could run some flavor of Unix on the Amiga. Four years ago, I did some work using IBM's PC/IX unixish operating system on an XT. Because the XT was such an unbelievably slow mahcine, it definitely wasn't much fun to work with. Santa Cruz Opeation aslo had Xenix for the XT -- without MMU or even math coprocessor. SCO's port even included troff. True -- there were were quite a few bugs, and cc was definitely brain-dead on memory models, but there was nothing fundamentally unworkable. Since the 680x0 has more addressing flexiblity, I don't see any reason why some form of Unix could not run on the Amiga. It would be helpful to use the 68010. The problem is that it definitely would take some effort, so there would have to be a good number of potential customers willing to buy it before I or anybody else would consider going to the effort. I suppose without an MMU it would be difficult to meet full commercial reliability criteria. One thing comes to mind. I have a recreational AT&T Unix PC at home to keep me busy when I get O.D.'ed on the Amiga. The Unix PC uses a 68010 and apparently very simple MMU that deals with fixed size pages. The Unix PC keeps the lower 512K for the kernel and the video display and walls users out of that space ... I think I've seen a similar achitecture somewhere; where could that be..? Perhaps a little daugherboard could be kludged up with an MMU that manages the fast RAM in 1K hunks and a 68010 could be stuffed into the Ami's regular 68000 socket. --Bill
lai@vedge.UUCP (David Lai) (04/26/88)
In article <211@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: >Has anyone bothered to think about writing a non-VM unix for the Amiga? >Buying a 68020/851 card for the 2000 just to run unix seems like a waste >to me. Also, if it indeed requires 100Meg disk (and can't be pruned down >to say... 10Meg) it will indeed be out of my league (I have no problem >leaving find/uucp/vi/uncompress/etc. on floppy). > >I don't think (could be wrong) that Xenix requires any sort of special >hardware (or gobs of file space). Therefore, why is Commodore writing I think you can run xenix on the bridgeboard. If commodore offers a VM-unix the user has a choice to step up to more power... if commodore offers only a non-vm unix, then you have no choice (2 non-VM unices). -- "What is a DJ if he can't scratch?" - Uncle Jamms Army The views expressed are those of the author, and not of Visual Edge, nor Usenet. David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)
harald@leo.UUCP ( Harald Milne) (04/30/88)
First off, what I say will be severely controversial and ideological. It might even contain religion. 8^) Take this with a grain of salt. In article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) writes: > Has anyone bothered to think about writing a non-VM unix for the Amiga? I like Dave Haynie's suggestion in the May issue of Amiga Sentry. It was, VM for AmigaDos. With the FFS, this is a very good suggestion. It could simply smoke a UNIX implemention. Add to this, remapping of the rom, to a 32-bit ram image, then protecting this as read only. Awesome. > Buying a 68020/851 card for the 2000 just to run unix seems like a waste > to me. It would be, were it not for the 68881. The MMU can also be put to use. Oh can it! Well, here is where I split off. As we all know, we have nearly a Sun workstation! If only a Sun had realtime response, and Amiga applications. (AMI versus Sparc ABI? 8^)) Given the above scenario, why screw around with UNIX at all? Think about it, a Sun workstation is virtually a single user machine. So is an Amiga. Only the Amiga doesn't pay the price of UNIX overhead (in multi-user chores) or lack of realtime response. Hmmmmm. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
dave@dms3b1.UUCP (Dave Hanna) (05/01/88)
In article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) writes: > Has anyone bothered to think about writing a non-VM unix for the Amiga? > Buying a 68020/851 card for the 2000 just to run unix seems like a waste > to me. Also, if it indeed requires 100Meg disk (and can't be pruned down > to say... 10Meg) it will indeed be out of my league (I have no problem > leaving find/uucp/vi/uncompress/etc. on floppy). > I see there are already follow-ups about the requirement for an MMU for a real UNIX. With respect to 100Megs on the disk, I tend to agree. 100 Megs would be nice to have, but, C-A, do you really have to make it a minimum? I worked on the Unisoft port of UNIX Sys V to the Dimension 68K in '84, and we ran the full system on a 22Meg drive (admitedly, without a lot of user space left over, but still.) I think as shipped, the disk had about 13M on it, plus a 2 M swap space. But that included over 2M of man pages. I am currently running on an ATT 3b1, with a 67Meg disk, running System V Release 3.51. Admittedly, it is missing a few things, but when I got it loaded up, it would come up and tell me that 89% of the disk was still available. (Of course, now that I'm running "news" on it, that's down to less than 20%! :^) ) The 100Megs would be nice to have, but can't we offer entry level options that are less? > Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin) > (...ucbvax!sun!sunncal!leadsv!laic!darin) -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
karl@sugar.UUCP (Karl Lehenbauer) (05/03/88)
In article <113@dms3b1.UUCP>, dave@dms3b1.UUCP (Dave Hanna) writes: > ... 100 Megs would be nice to have, but, C-A, do you really > have to make it a minimum? Agreed, for this and the rest of the system. The basic system should be priced with the minimum hard drive, the minimum amount of RAM and should not require the hires monochrome board. (I certainly hope the mono board is not required for Unix in any case.) Then it could be the price leader, or at least appear to be. Anyway, why shouldn't people be allowed to eke by with a small system if they want? And what's "small" anyway? Sugar, here, (a Unix system) started out with only forty meg, which was fine for a couple of people writing code, until we started running news, when we upgraded to 70 meg. Seventy meg is still a lot. Tektronix made the mistake several years ago with their Unix-based cross- development systems, of using a PROM to turn a 35 meg hard drive into a 13 meg hard drive to produce a low level system. Had they sold the 35 meg system at the 13 meg price, they would have captured valuable market share by having the clear price leader. As it was, they never did, and now they're out of the market. I worry about the Amiga. It is so clearly so much the best in so many ways, yet it hasn't achieved a large share of the personal computer market. I'd like to see a three hundred dollar A500, but then I'd like to see a cow fly, too, and since I have no idea what it costs to make and distribute one (A500), it may not be any more possible. By the way, does Commodore still make many/most of their own chips, or did that bit of vertical integration slip away? Heck, if you made it this far, we're friends, so I want to take this opportunity to make a philosophical statement about hacking and flame Apple: Apple made the Hacker's Machine, approx 1979 to 1984. With the introduction of the Mac, Apple abandoned the hackers. (The Mac II will retrieve some of them, but only the most affluent.) It's closed architecture, monochrome display and high price were off putting. With that, I think the IBM PC became the next Hacker's Machine, but we all knew it was pretty crappy. (Bill Gates, perhaps the most successful hacker in history, was reported in the Wall Street Journal as having angered many bigtime executives for calling the '286 "brain damaged." He knows it is, and we know it too.) The Amiga 1000, I think, was clearly the next Hacker's Machine, at least for software guys. Computer video hacks had been waiting a long time for an affordable NTSC machine. HAM was fortuitous. Apple, to me, proved that they have lost all hacker integrity when one of their spokespeople claimed that the GS's 65816 would be a better choice as a standard processor for CD-ROM standards than the 68000. No hacker with respectable credentials and a reputation to lose - no one who knows the score - could honestly make that claim. -k -- "I think Michael is like litmus paper - He's always trying to learn" - Liz Taylor ..!{bellcore!tness1,uunet!nuchat}!sugar!karl, Unix BBS (713) 438-5018
UH2@PSUVM.BITNET (Lee Sailer) (05/04/88)
One possible niche for an Amiga Unix would be student computer labs, or other places where the *functionality* of a full workstation is needed, but not the *performance*. I'd like my students to gain experience with a modern, multi-tsking, windowed, networked worksation environment. But the truth is they just don't do that many compiles that require 4MB, and they can get the feel for a modern interface without a 1200x800 pixel screen. So, Unix on the Amiga, in a networked environment so that the seats only need floppies (that is hard disk on server) with a MB of memory. If I could put 15 of those on a net with a big Vax or Sun or Apollo as a server, I'd be in heaven. Market Talk The "student lab" niche ain't very big. But I think there is a big niche for organizations that need something like Suns, but where each individual seat doesn't need a Sun. Office Automation, desktop pubs, executive email systems, corporate database, etc etc etc. Could or would an outfit like Sun produce a bottom of the barrel workstation? Or would it be easier for them to just license Amigas and put the Sun logo on them?? 8-)
hutch@net1.ucsd.edu (Jim Hutchison) (05/06/88)
In article <1872@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Now this article got corrupted, but apparently not to badly... >In article <3663@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: >> in article <211@laic.UUCP>, darin@laic.UUCP (Darin Johnson) says: >> > Has anyone bothered to think about writing a non-VM unix for the Amiga? >> > Buying a 68020/851 card... seems like a waste... >> You don't absolutely have to have virtual memory in a UNIX system, though >> ... that lots of stuff won't run without it... > >This isn't really an answer to the guy's question. To begin with it implies >that UNIX is a hog. System V might be a hog (though it's way better than >some of the proprietary operating systems certain well-known companies are >developing), but UNIX <> System V. Virtual memory, yes, the Amiga has it right now. Each process sees a linear address space based at 0, which is not based at physical 0. This is one form of virtual memory. If you take this and add swapping, you have a memory management system which will handle pre-paging unixes. This takes you up through various system V releases, but not the recent ones. Paging is still a nice preformance improvement, and *I* prefer the Berkeley "hacks" to the purity of the AT&T "features". As to Unix portability, E.M.U., IBM pc running Unix with an nd like filesystem. 640Kbytes of memory each, 2Mbyte root partition, and 8+Mbyte of read-only space shared between fellow clients for things like vi, Mail, more, etc.. (Note: EMU was a project, is a lab setup, was a paper, is not a product.) Yes, I thought about the question of Unix for the Amiga. No, Unix is not a hog, but I use this machine for play. !HACKS! Give me POPCLI, give me z, give me uedit, give me Zap (which I keep forgetting to send $$ to the author), give me messages to pass, drivers to bind, clipboards to share memory in, funky devices like the PIPE: device. I revel! Think of Mach. Mach is message passing (Unix-mod (please don't shoot, this is what I got from their presentation, I could be oh so very wrong)). Still there are always compatibility libraries. If I don't here of one by then, I will be doing fork()/wait() with tasks in the not so distant future. Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch ARPA: Hutch@net1.ucsd.edu Disclaimer: I represent my own opinions.
gsarff@ssdis.UUCP (gary sarff) (05/09/88)
In article <4928@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes: > > Virtual memory, yes, the Amiga has it right now. Each process sees a linear > address space based at 0, which is not based at physical 0. This is one > form of virtual memory. If you take this and add swapping, you have a memory > management system which will handle pre-paging unixes. This takes you up > through various system V releases, but not the recent ones. Paging is still > a nice preformance improvement, and *I* prefer the Berkeley "hacks" to the > purity of the AT&T "features". What? The amiga does scatter loading of executable images into its free RAM. this is not the same to me as virtual memory, and all the processes are in the SAME address space, (along with the OS itself). Real virtual memory would give each process ITS OWN address space starting at some point (zero say). "Each process sees a linear address space based at 0..." How does the process "see" this? Chances are on a busy amiga, it won't even get loaded into the same place(s) in RAM two times in a row, if a program prints the address of some memory structure, it will probably be a different address. In a virtual system it would always be the same, today, tomorrow, and next year. > Still there are always compatibility libraries. If I don't here of one > by then, I will be doing fork()/wait() with tasks in the not so distant > future. Good luck, I hope you can do it. I've been trying to do fork() on a protected mode non-unix OS at work that, unlike amigados, does keep track of resources given to a program, such as files open, memory/devices allocated, etc. and it is still a pain. Maybe under ARP that does do resource tracking, under amigados, it would be harder. -- Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff To program is human, to debug is something best left to the gods. "Spitbol?? You program in a language called Spitbol?" The reason computer chips are so small is that computers don't eat much.
dharvey@wsccs.UUCP (David Harvey) (05/27/88)
In article <134@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) writes: > In article <4928@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes: > What? > The amiga does scatter loading of executable images into its free RAM. this is > not the same to me as virtual memory, and all the processes are in the SAME > address space, (along with the OS itself). Real virtual memory would True. > give each process ITS OWN address space starting at some point (zero say). > "Each process sees a linear address space based at 0..." How does the process > "see" this? Chances are on a busy amiga, it won't even get loaded into the > same place(s) in RAM two times in a row, if a program prints the address of > some memory structure, it will probably be a different address. In a virtual > system it would always be the same, today, tomorrow, and next year. > Not always true! The virtual address will remain the same, but the actual physical location in memory doesn't stand a snowball's chance in h... of ever being the same, especially if there are a lot of pages being swapped in and out. Admittedly, this doesn't negate the fact that an Amiga programmer must assume much rf the oesponsibility that the OS should handle. But what can you expect from a system that is fitting into such a tiny space as AmigaDOS is in? Be reasonable! dharvey @ wsccs These aren't opinions, they are facts!
wes@obie.UUCP (Barnacle Wes) (05/28/88)
In article <134@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) writes: > Real virtual memory would > give each process ITS OWN address space starting at some point (zero say). > "Each process sees a linear address space based at 0..." How does the process > "see" this? Chances are on a busy amiga, it won't even get loaded into the > same place(s) in RAM two times in a row, if a program prints the address of Of course it wouldn't get loaded into RAM at the same place two times in a row - that is what you use virtual memory for! The idea is to put a Memory Management Unit (MMU) between the processor and the physical memory bus. When the processor wants to store/load to/from memory, it requests the location from the MMU. The MMU looks up this VIRTUAL address in a table of PHYSICAL ADDRESSES, and then reads or writes the physical RAM as appropriate. This table lookup is called a TRANSLATION. Usually, there is a table for the system and one table per user process. With this scheme, each process has it's own address space, so each process' memory can start at VIRTUAL address 0. BTW, virtual addresses are all you'd ever see in user mode. -- /|\ Barnacle Wes @ Great Salt Lake Yacht Club, north branch / | \ @ J/22 #49, _d_J_i_n_n_i /__|__\ ___|____ "If I could just be sick, I'd be fine." ( / -- Joe Housely, owner of _E_p_i_d_e_m_i_c -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
terry@wsccs.UUCP (Every system needs one) (05/28/88)
In article <237@obie.UUCP>, wes@obie.UUCP (Barnacle Wes) writes: > When the processor wants to store/load to/from memory, it requests the > location from the MMU. The MMU looks up this VIRTUAL address in a table > of PHYSICAL ADDRESSES, and then reads or writes the physical RAM as > appropriate. This table lookup is called a TRANSLATION. > > Usually, there is a table for the system and one table per user process. > With this scheme, each process has it's own address space, so each > process' memory can start at VIRTUAL address 0. BTW, virtual addresses > are all you'd ever see in user mode. Not necessarily so, Wes. You're forgetting about mapping memory-mapped I/O into a users address space, which is one of the many half-baked things a message passing operating system will do for you. Without the niceities of clist structs and what we in the software business like to call "usable interrupts", things like to write directly into your data segment. VMS does this too, more's the pity. When you do this, the MMU always maps your address to a known location in memory, and that location is never altered via swapping. Unf---ingortunately, Commodore had the idiocy to use a 68000 instead of a 68010 or 68020, just like Atari, so neither machine can properly support an MMU and are therefore not socketed, so the whole thing is moot, anyway. There will never be a good vmunix for a 68000. Now if you were to replace your 68000 with a 68010... terry@wsccs
hutch@net1.ucsd.edu (Jim Hutchison) (05/31/88)
(Be sure to double-check the attribution against the signature, and trim the quoted article down as much as possible.) In <547@wsccs.UUCP> dharvey@wsccs.UUCP (David Harvey) writes: >In <134@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) writes: >>In <4928@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes: <Hmmm, they trimmed me completely> > The amiga does scatter loading of executable images into its free RAM. >True. Actually, you don't have to scatter load. It probably helps things fit better if you can place hunks here there and everywhere, but you don't have to. It's an option on the Manx C compiler, one I have yet to excercise. Other than nasty check-pointing techinques which dump from .begin to .end to a file (I have never tried this on an Amiga, just a Vax & a Sun), what algorithms are impaired by a scattered memory configuration? >These aren't opinions, they are facts! Heavy. Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch ARPA: Hutch@net1.ucsd.edu Disclaimer: The cat agreed that it would be o.k. to say these things.
jgh@root.co.uk (Jeremy G Harris) (06/01/88)
In article <548@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >.... Unf---ingortunately, Commodore had the idiocy to >use a 68000 instead of a 68010 or 68020, just like Atari, so neither >machine can properly support an MMU and are therefore not socketed, so the >whole thing is moot, anyway. There will never be a good vmunix for a >68000. Unless you do as one company ( Arete? I forget ) did, back in the early days of 68000 unix systems, and use two 68000 processors. The second one was used purely for handling the page faults, while the primary processor was on hold. 68k chips are even cheaper now than they were then.... Cheers, Jeremy -- Jeremy Harris jgh@root.co.uk
kent@xanth.cs.odu.edu (Kent Paul Dolan) (06/09/88)
While the whole discussion is sort of vaporous anyway, I hear folks on opposite sides of the VM question talking past each other, so this is just a note to inject some commonality into the discussion. On a big, multiuser machine, Virtual Memory is a big win, because the swapping time is used by other processes needing time, and the lossage is limited to process switch times, page selection overhead, and perhaps some DMA cycle stealing as well. On a single user machine, all the swap time, if only a single task is executing, is direct lossage, plus all the overhead losses. Because of the slow hard disk transfer rates, there can be a significant slowdown perceptible to the user from choosing VM over added memory. Now choosing an efficient size for a working set of pages, and assuring by the choice of page sizes that the page fault rate is very low are made even more important than to the designer of the big multiuser machine. The other answer, of course, is a low priority ray tracer running on some hidden screen, so that even though the job in front of us runs considerably more slowly, we can smirk that we are putting all those excess cycles to use, unlike _some_ people we know. Kent, the man from xanth.
peter@sugar.UUCP (Peter da Silva) (06/12/88)
In article <217@toylnd.UUCP>, dca@toylnd.UUCP (David C. Albrecht) writes: > > 1) The 68000 supports an MMU just fine. > A single by itself 68000 does not to my knowledge 'support' an MMU. Having > a second 68000 which takes over on a page fault hardly constitutes 'support'. For the 14th time, an MMU does not imply demand paged virtual memory. There are plenty of reasons for having an MMU even if you can't handle page faults. Memory protection, for one, and providing a logical zero. Even if you can handle page faults you might not want to do more than kill the process with a SIGSEGV. Look at the PDP-11. > > 2) UNIX supports swapping just fine. > Ok. > > 3) Virtual memory often gives you virtual performance. > I've seen this kind of assertion many times on this newgroup and I still > think it is a crock. Comparing a PDP-11 running Berkeley UNIX (3BSD) with a VAX running Berkeley UNIX (4BSD). The PDP-11 gave a lot better response time, and supported more users, with less real memory than the VAX. And *this* was with an overlaid kernel in the '11! > > 4) You can have a damn good UNIX that isn't VM. > I agree. I don't, however, think that you can have a damn good UNIX that > doesn't have process protection which is usually part and parcel with > an MMU and thus VM. If you can find any indication that I even implied that (1) you can have a good UNIX without memory management, or (2) that an MMU and VM are equivalent. > Apples and Oranges. It has been a long time, but last time I used a PDP 11 > a process maxed out a 128K. Supporting many users each in a 128K > hunk is a lot easier than a bunch of users running in arbitrary size areas. > You can almost 'swap' a 128K hunk and get reasonable response for a fair > set of users. Kind of limits you to wenie processes though don't it? By the time 3BSD faded out, it had some amazing overlay support. You could take your VAX program with huge code and just compile and link it and it would automagically become overlaid. This is the system I'm talking about. About the only thing the VAX had that we PDP-11 weenies missed was Berkeley Job Control, and they got that after I left. As a side comment, the 128K limit *is* the reason paging wasn't implemented on the '11... even though the hardware supported it. > Of course virtual memory isn't free but neither is it that expensive > given that you have a reasonable amount of physical memory to back it up. I'm not saying that VM is undesirable, just that if you have enough memory that you never page (which is basically what you're talking about) you might as well not have the page table overhead. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
doug-merritt@cup.portal.com (06/13/88)
Peter da Silva wrote: >Comparing a PDP-11 running Berkeley UNIX (3BSD) with a VAX running Berkeley >UNIX (4BSD). The PDP-11 gave a lot better response time, and supported more >users, with less real memory than the VAX. And *this* was with an overlaid >kernel in the '11! This was true with earlier versions, too. Even *Version 6* Unix (as modified at Berkeley) could support 40 users on a PDP-11/70 with not-too- unreasonable response time. Or 25 users with *fast* response time. I saw 60 users on it many times (students at the end of the quarter), but the response time got ridiculous by that point. Still, I've never seen a VAX 11/780 running 40 users. I have seen it running 20. Slowly. To be fair, however, this is not altogether because a swapping Unix is faster than a paging Unix..there are several factors. Probably the biggest is that, when you've got plenty of memory, you use "too much" memory. People start writing stuff that's much bigger than it really needs to be, and that kills you when it needs to be paged. Look at the size of GNU software for a really good set of examples of this phenomena. Lots of features, but also remarkably large. Another factor is that the PDP 11 has a more efficient instruction set. The same program compiles smaller on the PDP 11 than on the VAX (you could say the PDP 11 is more RISC-like than the VAX), and that means there's less of it to swap on the 11 than to page on the VAX. And a final factor: I haven't looked at benchmarks, but some instructions at least run faster on the PDP than on the VAX...purely from an architectural point of view I would expect the PDP 11/70 to win most non-floating point benchmarks against the VAX 11/780. David Albrecht wrote: > Apples and Oranges. It has been a long time, but last time I used a PDP 11 > a process maxed out a 128K. Supporting many users each in a 128K > hunk is a lot easier than a bunch of users running in arbitrary size areas. > You can almost 'swap' a 128K hunk and get reasonable response for a fair > set of users. Kind of limits you to wenie processes though don't it? Yeah, the address space supported 64K of text and 64K of data. For some purposes that 128K is "wenie" indeed (e.g Franz Lisp, Macsyma, etc). On the other hand, it's *plenty* for the usual types of processes. For instance, it was in that environment that C shell and VI were developed. Never mind whether you like those utilities; the point is that they were large and complex, and their functionality has not increased very much since they moved to larger address spaces. At the time, the source code to each of these programs was larger than that of the PDP 11 Unix kernel. Both of these programs took up essentially *all* of the 64K of text space available to them, which I will grant limited the features Bill *could* add to them (as he lamented). But they are beyond the "wenie" stage even so. You can do an awful lot in 128K. Granted it's a real pain (as the 80286 is these days) when you *are* working on some huge project, but the other 99% of the software will fit just fine. (Hmmm...I'm really playing devil's advocate here. Usually I take the "we need more memory!" side of it.) Also, for the reasons you point out, it is often true that swapping *is* faster than paging. Peter said: >As a side comment, the 128K limit *is* the reason paging wasn't implemented on >the '11... even though the hardware supported it. As I recall there was a problem also with restarting certain instructions (i.e. you couldn't restart them after a page fault in their middle). This can sometimes be worked around via smart memory layout, but as you way, for 128K it's not really worth it. It's easier to tune paging to be fast anyway. All of the above is aimed simply getting some perspective on the issues. The PDP 11 was actually a better machine overall than the VAX. Problem is that address spaces larger than 128K are essential for *some* applications, and paging is very convenient for many of those same applications. Hence the VAX. It would've been better a better machine, though, if they'd just increased the size of the address space, rather than adding all those sexy but inefficient instructions. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
dca@toylnd.UUCP (David C. Albrecht) (06/14/88)
In article <2106@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <217@toylnd.UUCP>, dca@toylnd.UUCP (David C. Albrecht) writes: > > > 1) The 68000 supports an MMU just fine. > > A single by itself 68000 does not to my knowledge 'support' an MMU. Having > > a second 68000 which takes over on a page fault hardly constitutes 'support'. > > For the 14th time, an MMU does not imply demand paged virtual memory. There > are plenty of reasons for having an MMU even if you can't handle page faults. > Memory protection, for one, and providing a logical zero. Even if you can > handle page faults you might not want to do more than kill the process with > a SIGSEGV. Look at the PDP-11. Point granted but confusing. Why use a catch-all term when it isn't appropriate. Yes, the 68000 support memory protection and page relocation etc. By my definition, however, it doesn't support an 'MMU' unless it supports all the functions of a typical device which falls under this designation i.e. including demand paged VM. I guess your definition for 'support' is a little different. I wouldn't say that a FP chip 'supported' 'IEEE floating point' if it only did add and subtract. > > > > 3) Virtual memory often gives you virtual performance. > > I've seen this kind of assertion many times on this newgroup and I still > > think it is a crock. > > Comparing a PDP-11 running Berkeley UNIX (3BSD) with a VAX running Berkeley > UNIX (4BSD). The PDP-11 gave a lot better response time, and supported more > users, with less real memory than the VAX. And *this* was with an overlaid > kernel in the '11! > So? And you think the VAX would have done better in this comparison if you had taken out the VM and mapped direct to real memory? Uh huh. I respectfully suggest that conclusions drawn on a multi-variable problem through an intuitive leap to a pet-peeve result are often fraught with error. > > If you can find any indication that I even implied that (1) you can have a > good UNIX without memory management, or (2) that an MMU and VM are equivalent. I didn't say you implied it, and didn't even mean to imply that you implied it :-). I simply was making the point that VM is usually an available option once you have an MMU (my definition) in the system. And it is my opinion that VM is not high cost yet it provides very real benefits. > > By the time 3BSD faded out, it had some amazing overlay support. You could > take your VAX program with huge code and just compile and link it and it > would automagically become overlaid. This is the system I'm talking about. > About the only thing the VAX had that we PDP-11 weenies missed was Berkeley > Job Control, and they got that after I left. > > As a side comment, the 128K limit *is* the reason paging wasn't implemented on > the '11... even though the hardware supported it. > Maybe you should convince the people at BSD that they should put an intelligent overlay manager on the VAX so that everyone will be paging in and out of a 128K segment instead of using up all of memory. Bongo roll....bump rest bump bump bump rest bump bump bump rest...flute run. Lights fuse.....Good luck. > > Of course virtual memory isn't free but neither is it that expensive > > given that you have a reasonable amount of physical memory to back it up. > > I'm not saying that VM is undesirable, just that if you have enough memory > that you never page (which is basically what you're talking about) you might > as well not have the page table overhead. I could have a virtual size which was 50% larger than my real memory and I would probably rarely page. I could put in physical memory but I have a disk, I have an MMU (my definition), it doesn't cost much, why not use VM? I also have the option to run processes that won't go in real memory. Maybe they will run poorly but they will run. That is more than you can say for real memory only machines. VM gives you a valuable commodity, flexibility. You can be cheap yet sacrifice only performance instead of compatability. The 3b1 on my desk has 3M of memory in it and a 4M virtual space. There are people out there with 512K machines (gack!) who can run all the same stuff I can, slow but they can run it. No one has ever said that VM is better than the real stuff just that it provides the effect of real memory. It has always been and will always be a cost/performance tradeoff. There is still an order of magnitude price of memory/price of rotating media. If you don't use VM you have lost very little. If you need it and don't have it you are shit out of luck. David Albrecht
greg@isrnix.UUCP (Gregory Travis) (06/15/88)
This should probably migrate to some other newsgroup, but in defense of
the PDP-11 I've gotta jump in. Isrnix is a PDP-11/44 with 2.5Meg of main
memory and a little over 300 meg of disk space. We can comfortably support
15-20 users and have hit 30 users a couple of times (which is painful).
The machine Dhrystones about the same as my Amiga (which also has 2.5Meg).
We've got all the "big machine" stuff, such as a 75IPS tape drive, 54
serial ports, multiple dialin/dialout lines, and three disk controllers.
We're running ISR 2.9BSD and have full emacs, job control, etc.
Quite a bit for a 128K machine.
--
Gregory R. Travis
Institute for Social Research - Indiana University - Bloomington, IN 47405
ihnp4!inuxc!isrnix!greg
{pur-ee,kangaro,iuvax}!isrnix!gregpeter@sugar.UUCP (Peter da Silva) (06/16/88)
In article <6469@cup.portal.com>, doug-merritt@cup.portal.com writes: > Peter said: > >As a side comment, the 128K limit *is* the reason paging wasn't > >implemented on the '11... even though the hardware supported it. > As I recall there was a problem also with restarting certain instructions > (i.e. you couldn't restart them after a page fault in their middle). Since PDP-11 UNIX used this capability to automatically extend the stack frame of processes, and because just about any instruction could be used in the stack, I doubt if there was any real problem here... at least not for user mode instructions. And ask the people who have ported the bourne shell to the 68000 what sort of problems you'd expect if this didn't work right... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
peter@sugar.UUCP (Peter da Silva) (06/20/88)
Well, I'll just say one thing... back when I was first introduced to the concept of a memory management unit demand paged virtual memory was an extremely exotic concept for machines smaller than mainframes. There was no such machine as a vax. Even today, the beast you're talking about is generally referred to as a PMMU. Of course back then even a non-P MMU was considered an option rather than a necessity even for machines like the PDP-11. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
erikj@hi.unm.edu (Erik Johannes) (06/20/88)
I believe one of the key issues to implementing UNIX or MINIX or any of the other Unix clones is the fork command. A fork command makes a copy of the process. This includes not only the code but also the data. Copying the data is were a plain 68000 without an MMU runs into problem. The 68000 doesn't necessarily know were all the data is. It may know were the main data segment is, but there can be pointers in there pointing else were. In order for the fork command to function properly the 68000 would have to chase down all the pointers and stuff, which would be extremely complex and time consuming. One of the principal foundations of UNIX is cheap processes, and this is not possible with a plain 68000. One of the work arounds for this problem is the "forkexec" command. I believe the Amiga has this. But this is not a true fork command and thus not compatable with UNIX. Intel got lucky with their convoluded segment registers in the 80x86 family. Since there is a Data base register, they can make a copy of the data segment and therefore have a true fork. For a 68k system, one must have an MMU or a 68020 (68030) which has a built in MMU. -Erik Johannes
daveh@cbmvax.UUCP (Dave Haynie) (06/21/88)
in article <23602@hi.unm.edu>, erikj@hi.unm.edu (Erik Johannes) says: > In order for the fork command to function properly the 68000 would have to > chase down all the pointers and stuff, which would be extremely complex and > time consuming. If at all possible, which it might not be. Your fork routine would have to identify somehow every data item that's a pointer. No real way to do this. One alternate non-MMU method is to do a real CPU copy of the data to the base location, which would achieve the same effect as the MMU, but be far to slow for any practical use. > One of the principal foundations of UNIX is cheap processes, Compared to the above, perhaps. But UNIX processes are certainly more expensive than AmigaOS processes. Which is why they created "threads" in Mach. > Intel got lucky with their convoluded segment registers in the 80x86 > family. Since there is a Data base register, they can make a copy of the > data segment and therefore have a true fork. If you wanted to restrict your 68000 system in the same way as the 80x86, to 64K segments, you could allow only register relative code to be used. This would give you a fork that's just as good as any on the 80x86 machines. > For a 68k system, one must have an MMU or a > 68020 (68030) which has a built in MMU. Only the 68030 has a built-in MMU. Though the 68020 works quite nicely with the 68851 PMMU. > > -Erik Johannes -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
doug-merritt@cup.portal.com (06/21/88)
David Albrecht responds to Peter da Silva: >Point granted but confusing. Why use a catch-all term when it isn't >appropriate. Yes, the 68000 support memory protection and page relocation >etc. By my definition, however, it doesn't support an 'MMU' unless it >supports all the functions of a typical device which falls under this >designation i.e. including demand paged VM. I guess your definition for >'support' is a little different. Both of your definitions are fairly common usage, so you are both right. I found out the hard way, though, that if you *mean* demand paged (say in writing a requirements document), you must *say* "demand paged", otherwise the ambiguity in other people's interpretation of your comments will bite you. In general, "Memory Management Unit" is a very general term (think about the individual words), yet people will tend to interpret it in terms of what they are used to. I used to program on 8080's and z80's, and I would have loved to have any kind of MMU at all, regardless of definition. (And eventually got the manufacturer I worked for to add in a simple memory base segment protection MMU, but that's another story.) I've programmed in the 80286 and the PDP 11/70 environment, and its MMU is far better than having none at all, even though it doesn't support demand paging VM. To say that such machines do not have an MMU is only going to create confused conversations with people with that kind of background, since to us it has become very clear that it is very useful to have a way to keep buggy programs from bringing down the whole system. And since this more general usage of the term MMU is very common industry-wide, and since there's good logical reason to use the term generally, you're not going to be able to change other people's usage. Nor do I expect to keep people from saying MMU when they mean "demand paged VM", I just ask for clarification as to which *kind* of MMU they mean. I've also worked with VAXEN, DEC 20's, Suns, and other systems with demand paged VM, and I agree that all that is real nice. I've even spent considerable time on a mainframe VM architectural design project. It seems that the more different environments I've encountered, the less I feel like there's only one way to do things, or only one definition of technical terms. >I wouldn't say that a FP chip 'supported' >'IEEE floating point' if it only did add and subtract. I would, although I qualify that as supporting "a subset of the IEEE standard". Why belittle it??? Having only hardware FP add and subtract will still speed up all FP operations considerably compared with having none at all. I see no point in forcing a choice between calling something either white or black, when you can call it a shade of grey instead. >I respectfully suggest that conclusions drawn on a multi-variable problem >through an intuitive leap to a pet-peeve result are often fraught with error. I agree, and I further suggest that just about all of us make such errors anyway. All one can do is be open minded... >VM gives you a valuable commodity, flexibility. You can be cheap yet >sacrifice only performance instead of compatability. Totally agree. Much more important point than mere terminology. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (06/21/88)
From article <4071@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): " If you wanted to restrict your 68000 system in the same way as the 80x86, " to 64K segments, you could allow only register relative code to be used. " This would give you a fork that's just as good as any on the 80x86 machines. It was my understanding that the 80386 is not restricted to 64k segments. Greg, lee@uhccux.uhcc.hawaii.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/22/88)
:time consuming. One of the principal foundations of UNIX is cheap processes, :and this is not possible with a plain 68000. One of the work arounds for this :problem is the "forkexec" command. I believe the Amiga has this. But this :is not a true fork command and thus not compatable with UNIX. Er, since when is the principal foundation of UNIX a cheap process? Whatever they are, they aint cheap! : Intel got lucky with their convoluded segment registers in the 80x86 :family. Since there is a Data base register, they can make a copy of the :data segment and therefore have a true fork. For a 68k system, one must :have an MMU or a 68020 (68030) which has a built in MMU. : : -Erik Johannes Usually, when you get to that point, you want an MMU anyway. But, in essence, I would agree that a limited UNIX could be run on the 80x86 without an MMU. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/22/88)
>If you wanted to restrict your 68000 system in the same way as the 80x86, >to 64K segments, you could allow only register relative code to be used. >This would give you a fork that's just as good as any on the 80x86 machines. > >> For a 68k system, one must have an MMU or a >> 68020 (68030) which has a built in MMU. Assuming that you don't have any pointers hanging around. Which you can do ... make all pointers 16 bit integers and then whenever you make a pointer reference offset it by A4 (or whatever). But frankly, this would cause more harm than good and be awefully slow! More harm than good, because all those standard Amiga structures use normal 32 bit pointers, and one is bound to have a couple of them lying around! -Matt
doug-merritt@cup.portal.com (06/22/88)
Erik Johannes writes: >For a 68k system, one must >have an MMU or a 68020 (68030) which has a built in MMU. Nominally, yes. The other way to do it is via software support. It is quite feasible to construct compilers/assemblers/linkers etc which force all data storage to be in a separate memory area than text, and which uses base-register addressing to get at that data. You can then do the same sort of thing as on an 80286...just reset the register used for base addressing and you've got yourself a new data space. But AmigaDOS facilities use a lot of absolute pointers within the users' "address space", so making fork() work for regular AmigaDOS processes would be very difficult, to say the least. But if you ran Minix instead, then you could get fork to work. The one thing that would still be missing is that a program could still conceivably accidentally set a "segment register" incorrectly and start zapping other "address spaces". This could be minimized by careful compiler code generation, but presumably *could* happen anyway. Whereas on the 286, the MMU will not allow you to poke around in the wrong segments. So on 68K systems, you *can* implement fork(). You just have to do it with the right OS, and you don't get MMU protection. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
daveh@cbmvax.UUCP (Dave Haynie) (06/22/88)
in article <1985@uhccux.uhcc.hawaii.edu>, lee@uhccux.uhcc.hawaii.edu (Greg Lee) says: > From article <4071@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): > " If you wanted to restrict your 68000 system in the same way as the 80x86, > " to 64K segments, you could allow only register relative code to be used. > " This would give you a fork that's just as good as any on the 80x86 machines. > It was my understanding that the 80386 is not restricted to 64k segments. This is true. However, the discussion my above quote was extracted from was talking about how segmentation on the original 8088 and on up was an advantage since it lets you run a fork-able OS. My point was that the 68000 can do the exact same thing if you restrict all code and data to being register relative. Which magically results in the same 64K limitations you'd get with an 8088 or so. An 80386, in it's native mode, will handle larger segments. It's also competing with 68020/68851 and 68030s, not 68000s. They are all capable of running a VAX-like rather than PDP-11-like UNIX. > Greg, lee@uhccux.uhcc.hawaii.edu -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
darin@nova.laic.uucp (Darin Johnson) (06/23/88)
> :One of the principal foundations of UNIX is cheap processes, > :and this is not possible with a plain 68000. > > Er, since when is the principal foundation of UNIX a cheap process? > Whatever they are, they aint cheap! Actually, I thought they were quite cheap. Of course, I am forced to work on VMS systems most of the time: a SPAWN command back when we had 11/780's was generally frowned upon as being wasteful of CPU, and user's were only allowed a maximum of 1 process. Nowdays, with the 8650, a SPAWN only takes about 5 seconds :-) Darin Johnson (...pyramid.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"
DMasterson@cup.portal.com (06/24/88)
Let's try to bring this topic back to the original question (at least I think it was the original question -- its been so long off the topic, I forgot). I think the question at hand is what it would take to implement Unix (or A VAR- IATION THEREOF) on an Amiga (not a souped-up Amiga). In that question, has anyone heard of/seen Amix by Lamplighter Software (I think). Its been advertised in Amazing Computing, but, thus far, I haven't heard anyone say anything about it. David Masterson DMasterson@cup.portal.com
mwjones@lion.waterloo.edu (Morgan Jones) (06/24/88)
>It was my understanding that the 80386 is not restricted to 64k segments. Right. It has 16M segments (or some other huge number). > Greg, lee@uhccux.uhcc.hawaii.edu -- Morgan Jones mwjones@lily.waterloo.edu
peter@sugar.UUCP (Peter da Silva) (06/24/88)
In article ... dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann) writes: > (1) MINIX _does_ run on an ATARI ST, a true 68000, thus it is > obviously possible to do a fork() on a 68000 ... MINIX on the ST actually copies forked data during a context switch, giving you extremely slow performance until you give up and exec() or exit() one of the programs. This is also, by the way, how the old LSI-11 no-MMU UNIX handled it, though that one did it by swapping the forked data on and off a floppy. AT least MINIX doesn't try to do that. No, the only way to do this is with position-independant code and base registers for data. You'd be better off with an 80286, at this point... since you've just picked up most of the '286 problems without any of the advantages. > (3) True, a 68020 w/ MMU would sure help, but have you seen a > amiga w/ 68020 and MMU recently? No, but I've seen one with a 68020 and an MMU socket. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
gsarff@ssdis.UUCP (gary sarff) (06/25/88)
In article <4071@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <23602@hi.unm.edu>, erikj@hi.unm.edu (Erik Johannes) says: > > > One of the principal foundations of UNIX is cheap processes, > > Compared to the above, perhaps. But UNIX processes are certainly more > expensive than AmigaOS processes. Which is why they created "threads" > in Mach. Threads are like shared libraries in the sense that they give you an advantage if you have more than 1 process using them. A shared library with only one process using it gives you nothing more than if the library routines were actually in the programs load image. With 2 or more programs you reap an advantage. Same with threads, if you have only 1 thread in a process, it isn't any "cheaper" than a unix process. It still has a process or task control block, a stack, a heap, a place to store its registers when it is context switched etc, just like a heavy process. Only if the process is really executing multiple threads of itself do you get any advantage at all. If I have on my amiga running, 1 word processor, 1 spreadsheet, 1 photon paint, 1 comm program, they are all different processes all single threaded, no advantage is gained. Threads would be much better if one had fork() in an OS like unix, then the OS could just create another thread of the calling process instead of copying the core image again. Threads are nicer yes, but do many amiga programs use them, i.e. are there any multi-threaded "application" programs? -- Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff To program is human, to debug is something best left to the gods. "Spitbol?? You program in a language called Spitbol?" The reason computer chips are so small is that computers don't eat much.
egranthm@jackson.UUCP (Ewan Grantham) (06/25/88)
I'm just curious after all this discussion of how Commodore IS planning to
implement Unix on the A2500?
As an aside, anyone out there working on a port of the news software to the
Amiga? I'm tired of things getting changed at work while I'm not watching,
and losing my news feed (a whole week this time). Figure I can keep better
control at home, but need to be able to be polled, and UUPC doesn't do that.
Anyway, have started looking at it, but would appreciate any help.
Yours,
Ewan Grantham
--
Ewan Grantham (601) 354-6454 ext.358
...!uunet!nuchat!jackson!egranthm or
{pyramid or bellcore or tness..}!swbatl!jackson!egranthm
I'm not responsible for my bosses, and vice-versaelg@killer.UUCP (Eric Green) (06/25/88)
In message <8806212043.AA00625@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >>If you wanted to restrict your 68000 system in the same way as the 80x86, >>to 64K segments, you could allow only register relative code to be used. >>This would give you a fork that's just as good as any on the 80x86 machines. > Which you can do ... make all pointers 16 bit integers and then >whenever you make a pointer reference offset it by A4 (or whatever). >But frankly, this would cause more harm than good and be awefully slow! Actually, using 16-bit relative addressing is FASTER, on a 68000, than full 32-bit direct addressing. Don't believe me? Go look at the cycle count in your 68000 assembler manual. There's a reason the Manx compiler has a "small" model, and that's it. Manx doesn't extend that paridigm to the heap, however, as an Amiga Unix would have to do, because of the 32-bit pointers used by Amiga OS etc. > More harm than good, because all those standard Amiga structures >use normal 32 bit pointers, and one is bound to have a couple of them lying >around! If one is implementing a Unix operating system on the Amiga, why in the world would you want to have a couple of 32-bit pointers to AmigaDos hanging around? No, the primary argument is simply that most modern Unix programs will not fit in a 64K address space, and thus Unix on a 68000 sans MMU could never be more than a toy. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie if it don't come true, or is it something worse?"
peter@sugar.UUCP (Peter da Silva) (06/25/88)
In article <6811@cup.portal.com>, DMasterson@cup.portal.com writes: > Let's try to bring this topic back to the original question (at least I think > it was the original question -- its been so long off the topic, I forgot). I > think the question at hand is what it would take to implement Unix (or A VAR- > IATION THEREOF) on an Amiga (not a souped-up Amiga). Well, you can't implement enough of UNIX to make it worthwhile, because you don't have any way of implementing the "fork()" system call without causing a huge performance penalty. Now, people counter that most programs follow a fork() with an exec(). I guess most do, but many interesting programs I know of do things like "if(fork()) exit();", or "if(fork()) { do something strange and bizzarre to file descriptors and signals and maybe even do some I/O then exec(); }", or "if(fork()) server(); else client();", and so on. > In that question, has > anyone heard of/seen Amix by Lamplighter Software (I think). Its been > advertised in Amazing Computing, but, thus far, I haven't heard anyone say > anything about it. I called them. They promised to send more info. I haven't gotten anything from them. I guess I could call again, come Monday. They claimed (over the phone) that it's a nearly complete UNIX environment and it runs under AmigaDOS. I think I managed to rule out a utility set like MKS Toolkit and the MKS shell on the IBM-PC, but won't swear to it. I am reminded of the responses I got when I asked substantially the same questions of a company that was advertising UNIX for the Atari ST. They claimed that it was substantially UNIX, but not that it ran under TOS. As far as I know it never shipped. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
peter@sugar.UUCP (Peter da Silva) (06/25/88)
In article ... mwjones@lion.waterloo.edu (Morgan Jones) writes: > >It was my understanding that the 80386 is not restricted to 64k segments. > Right. It has 16M segments (or some other huge number). Try 4 gigabytes. Which means that for practical purposes you can ignore the segmentation. Unless you're a PL/M junkie who *likes* the things. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
jesup@cbmvax.UUCP (Randell Jesup) (06/26/88)
In article <142@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: >Threads are like shared libraries in the sense that they give you an >advantage if you have more than 1 process using them. A shared library >with only one process using it gives you nothing more than if the library >routines were actually in the programs load image. With 2 or more programs Not quite correct: shared libraries are better (in some ways) than linking into the executable for several reasons: 1) late binding; 2) smaller executable. Late binding means you can fix routines without having to re-link/compile the programs, etc. >Same with threads, if you have only 1 thread in >a process, it isn't any "cheaper" than a unix process. It still has a >process or task control block, a stack, a heap, a place to store its >registers when it is context switched etc, just like a heavy process. Only >if the process is really executing multiple threads of itself do you get >any advantage at all. This sounds an awful lot like copy-on-write in software. What happens if one of the threads does an exec()? -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jesup@cbmvax.UUCP (Randell Jesup) (06/26/88)
In article <4585@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >There's a reason the Manx compiler has a "small" model, and that's it. >Manx doesn't extend that paridigm to the heap, however, as an Amiga >Unix would have to do, because of the 32-bit pointers used by Amiga OS >etc. Actually, I think the initial reason is that it was based on their Mac compiler, which has to generate such code. Note that 3.10 Lattice and later have "small model" code, with a max of 64K data in it (though it allows modules to be mixed (carefully) with "large model" code). 4.0 Lattice has support for short integers as well, and defaults to "small model". -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.UUCP (Peter da Silva) (06/26/88)
In article <142@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) writes: > If I have on my amiga running, 1 word processor, > 1 spreadsheet, 1 photon paint, 1 comm program, they are all different > processes all single threaded, no advantage is gained. Threads would be > much better if one had fork() in an OS like unix, then the OS could just > create another thread of the calling process instead of copying the > core image again. Threads are nicer yes, but do many amiga programs use > them, i.e. are there any multi-threaded "application" programs? One thing you have to bear in mind is that from the point of view of overhead Amiga processes *are* threads. There really isn't a smaller thread of control flow that you can create on the Amiga. You can go to tasks, but that really doesn't take up significantly fewer resources... about all you gane is the DOS process header. The CPU-time difference is nil. As for multi-threaded application programs: check out haicalc. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
jesup@cbmvax.UUCP (Randell Jesup) (06/27/88)
In article <2176@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Well, you can't implement enough of UNIX to make it worthwhile, because you >don't have any way of implementing the "fork()" system call without causing >a huge performance penalty. Now, people counter that most programs follow >a fork() with an exec(). I guess most do, but many interesting programs I >know of do things like "if(fork()) exit();", or "if(fork()) { do something >strange and bizzarre to file descriptors and signals and maybe even do some >I/O then exec(); }", or "if(fork()) server(); else client();", and so on. All you need to do a fork() is to copy the data/stack segments on task swaps between those two. After a fork, you'd probably let the child run for a while, hoping it will exit, exec, or some such soon. Otherwise, your task switches for those two processes will be much slower. But then again, Unix doesn't claim to be real-time either. Luckily, VERY few programs fork without exec()ing or exit()ing soon thereafter (though they often muck with fd's, etc first.) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.UUCP (Peter da Silva) (06/27/88)
In article <4112@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > All you need to do a fork() is to copy the data/stack segments on > task swaps between those two. My claim is that this gives you an unacceptable speed penalty. One of the most common programs that does fancy stuff with forks is the shell. Every time you run a script that does something like: cat file | while read FOO BAR JUNK; do frobb $FOO | baz $BAR; done | ... That 'while' (according to the docs: I haven't seen the Bourne shell source) runs in a forked subshell. Now all you have to do is stick this in the background, or do this twice, and you die die die die... > Luckily, VERY few programs > fork without exec()ing or exit()ing soon thereafter (though they often > muck with fd's, etc first.) Yeh, the shell is the only one I can think of that I use often :->. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
jesup@cbmvax.UUCP (Randell Jesup) (06/28/88)
In article <2188@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <4112@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> All you need to do a fork() is to copy the data/stack segments on >> task swaps between those two. >cat file | while read FOO BAR JUNK; do frobb $FOO | baz $BAR; done | ... > >That 'while' (according to the docs: I haven't seen the Bourne shell source) >runs in a forked subshell. Now all you have to do is stick this in the >background, or do this twice, and you die die die die... The shell(s) are part of the system. There are ways around it, of course that requires mods to the shell. So what? It's user/application/pd/ whatever programs where this matters, since anything that's part of the system can work around the slowness of fork()s that don't exec/exit. Also, most (99%? - don't flame, it's just a guess) of pipe invocations don't involve the shell executing lots of subshells that don't exec. In fact, I think I've never done so. So long as only one of the shell subprocesses is actually doing any processing, there's no extra overhead. >> Luckily, VERY few programs >> fork without exec()ing or exit()ing soon thereafter (though they often >> muck with fd's, etc first.) > >Yeh, the shell is the only one I can think of that I use often :->. Like I said VERY few. How many different shells do you run on your system? 2? 3? How many of them are user-written programs (i.e. not obtained with the system)? -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
gsarff@ssdis.UUCP (gary sarff) (06/28/88)
In article <4109@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <142@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: > >Threads are like shared libraries in the sense that they give you an > >advantage if you have more than 1 process using them. A shared library > Not quite correct: shared libraries are better (in some ways) than > linking into the executable for several reasons: 1) late binding; 2) smaller > executable. Late binding means you can fix routines without having to > re-link/compile the programs, etc. You're right. I was just considering execution benefits though. > > >process or task control block, a stack, a heap, a place to store its > >registers when it is context switched etc, just like a heavy process. Only > >if the process is really executing multiple threads of itself do you get > >any advantage at all. > > This sounds an awful lot like copy-on-write in software. What happens > if one of the threads does an exec()? If one of the threads did an exec you would need some kind of copy-on-write either hardware or software. My point was that I have seen a great many statements like "unix processes are heavy, amiga's processes are light so ours are better". I was just making the point that threads buy you little "lightness" if there is only one process per thread. -- Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff To program is human, to debug is something best left to the gods. "Spitbol?? You program in a language called Spitbol?" The reason computer chips are so small is that computers don't eat much.
dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann) (06/28/88)
From article <257@jackson.UUCP>, by egranthm@jackson.UUCP (Ewan Grantham): > > I'm just curious after all this discussion of how Commodore IS planning to > implement Unix on the A2500? > They'll use an 68020 with a MMU (68881?). > ... > > Yours, > Ewan Grantham > > -- > Ewan Grantham (601) 354-6454 ext.358 > ...!uunet!nuchat!jackson!egranthm or > {pyramid or bellcore or tness..}!swbatl!jackson!egranthm > I'm not responsible for my bosses, and vice-versa -Dirk ------------------ Smile, tomorrow will be worse! ------------- Business: Dirk Husemann Home: Dirk Husemann Friedrich-Alexander University Aufsess-Str. 19 Erlangen-Nuremberg D-8520 Erlangen Comp.Science Dep. IMMD IV West Germany Martensstrasse 1 +49 9131 302036 D-8520 Erlangen West Germany +49 9131 857908 email: dkhusema@faui44.informatik.uni-erlangen.de ------------------ Did I say smile? Forget it! ---------------- Disclaimer: The opinions, views, statements, ..., expressed here are NOT those of the university nor those of the student body as a whole. In fact, they're mine! ---------------------------------------------------------------
peter@sugar.UUCP (Peter da Silva) (06/28/88)
In article <4124@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <2188@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >In article <4112@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > >> All you need to do a fork() is to copy the data/stack segments on > >> task swaps between those two. > >cat file | while read FOO BAR JUNK; do frobb $FOO | baz $BAR; done | ... > >That 'while' (according to the docs: I haven't seen the Bourne shell source) > >runs in a forked subshell. Now all you have to do is stick this in the > >background, or do this twice, and you die die die die... > The shell(s) are part of the system. There are ways around it, of > course that requires mods to the shell. So what? The shells(s) are just another application program. If you don't believe me, call the AT&T Software Toolchest and inquire about korn shell sources. I do NOT want a UNIX that requires me to make extensive mods to ksh to make it run. > It's user/application/pd/ > whatever programs where this matters, since anything that's part of the system > can work around the slowness of fork()s that don't exec/exit. And I don't want the guy doing the port wasting his time on application programs when he could be adressing systems problems. Go have a talk to the guys on comp.unix.microport about where that can lead. Talk to your local Xenix site about shells that forget to keep history. We're talking a major project to get UNIX running under AmigaDOS anyway. Why make things harder by porting to hardware that doesn't like UNIX? Install an MMU, for gods sake. Ship UNIX with a daughterboard containing at least a 68010 and an MMU. AmigaDOS likes the 68010 just fine... > Also, most (99%? - don't flame, it's just a guess) of pipe invocations > don't involve the shell executing lots of subshells that don't exec. In fact, > I think I've never done so. So long as only one of the shell subprocesses is > actually doing any processing, there's no extra overhead. Have a look at /usr/bin/cal if you have a SYSV system. Now, the following is a straw man... just because something is shipped with the system doesn't mean it's done right: if it were, then there wouldn't be a BUGS (or "RESTRICTIONS :->) section in the UNIX manual and all commands would use perror(). But I'll address it anyway. > >> Luckily, VERY few programs > >> fork without exec()ing or exit()ing soon thereafter (though they often > >> muck with fd's, etc first.) > >Yeh, the shell is the only one I can think of that I use often :->. > Like I said VERY few. How many different shells do you run on your system? > 2? 3? 4, actually: sh, csh, ksh, and browse. > How many of them are user-written programs (i.e. not obtained with the > system)? 2, ksh and browse. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
jesup@cbmvax.UUCP (Randell Jesup) (06/29/88)
In article <146@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: >In article <4109@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> >process or task control block, a stack, a heap, a place to store its >> >registers when it is context switched etc, just like a heavy process. Only >> >if the process is really executing multiple threads of itself do you get >> >any advantage at all. >> This sounds an awful lot like copy-on-write in software. What happens >> if one of the threads does an exec()? >If one of the threads did an exec you would need some kind of copy-on-write >either hardware or software. My point was that I have seen a great many >statements like "unix processes are heavy, amiga's processes are light so >ours are better". I was just making the point that threads buy you little >"lightness" if there is only one process per thread. You're mixing up "light" processes (aka small switching overhead), with "threads" (some sort of term from mach(?) for multiple subtasks of a process in the same "heavy" unix process). We have light processes, i.e. the task switching overhead is very small compared to most Uni. We CAN have threads, if the programmer wants to use them (CreateProc, AddTask). And some programs do. But the overhead for a "thread" is the same in AmigaDos as the overhead for a process. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jesup@cbmvax.UUCP (Randell Jesup) (06/29/88)
In article <2210@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> The shell(s) are part of the system. There are ways around it, of >> course that requires mods to the shell. So what? > >The shells(s) are just another application program. If you don't believe me, >call the AT&T Software Toolchest and inquire about korn shell sources. I do >NOT want a UNIX that requires me to make extensive mods to ksh to make it >run. We're not talking a professional Unix here. Commodore has made no mention of Un*x on a 68000 amiga, has it? We're just talking how one would go about porting something like Minix to the amiga. If you think anything more is going on here peter, you're sadly mistaken (and no, Commodore is not porting Minix either. My comments come from when I was at GE, and was part of the Amiga-minix mailing list on the internet, before it died.) >> It's user/application/pd/ >> whatever programs where this matters, since anything that's part of the system >> can work around the slowness of fork()s that don't exec/exit. > >And I don't want the guy doing the port wasting his time on application >programs when he could be adressing systems problems. Go have a talk to the >guys on comp.unix.microport about where that can lead. Talk to your local >Xenix site about shells that forget to keep history. Please read the rest of the context - I said that almost NO application programs require this, and why would someone porting a Un*x bother with porting every appllication in the world: just document how to do it if you REALLY need to. Things will work if you don't bother, just more slowly. >We're talking a major project to get UNIX running under AmigaDOS anyway. Why >make things harder by porting to hardware that doesn't like UNIX? Install an >MMU, for gods sake. Ship UNIX with a daughterboard containing at least a >68010 and an MMU. AmigaDOS likes the 68010 just fine... Why do you think C= is doing Un*x for the C= 68020 board, which comes with a 68851 MMU? Note Unix also likes lots of memory, which is why the board has space for memory as well (max I think is 4 meg on board.) >> Also, most (99%? - don't flame, it's just a guess) of pipe invocations >> don't involve the shell executing lots of subshells that don't exec. In fact, >> I think I've never done so. So long as only one of the shell subprocesses is >> actually doing any processing, there's no extra overhead. > >Have a look at /usr/bin/cal if you have a SYSV system. Sorry, I use a sun. It's an executable here. (Sys V seems to do EVERYTHING in scripts, sheesh - even man and cc are scripts.) >Now, the following is a straw man... just because something is shipped with >the system doesn't mean it's done right: if it were, then there wouldn't >> Like I said VERY few. How many different shells do you run on your system? >> 2? 3? > >4, actually: sh, csh, ksh, and browse. So you're unusual. >> How many of them are user-written programs (i.e. not obtained with the >> system)? >2, ksh and browse. So if you port them to this hypothetical system that no one is doing, read the still-non-existant docs and use them to do it right. Or live with whatever shells the hypothetical writer ported for you. SHEESH! -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
daveh@cbmvax.UUCP (Dave Haynie) (06/29/88)
in article <354@faui44.informatik.uni-erlangen.de>, dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann) says: > > (3) True, a 68020 w/ MMU would sure help, but have you seen a > amiga w/ 68020 and MMU recently? I'm typing on one. You'll probably have to wait a few months, and spend some big dollars, to enjoy the same thing. But they do exist. > -Dirk Husemann > West Germany ^^^ Oh, Germany. You might even be able to get one sooner. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
daveh@cbmvax.UUCP (Dave Haynie) (06/29/88)
in article <142@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) says: > Summary: 2 threads are cheap > Threads are nicer yes, but do many amiga programs use them, i.e. are there any > multi-threaded "application" programs? Probably not as many as there should be. Certainly most device drivers are multi-threaded. And I've also seen it used in video games (for example, each "Nasty" is a task, and you run N instances of that task for N "Nasties"). In between I haven't seen it used as much, but I suspect part of the reason for this is that most programmers aren't confortable with using multiple tasks within a single program. Regardless of whether they're multi-threaded or not. > Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
daveh@cbmvax.UUCP (Dave Haynie) (06/29/88)
in article <146@ssdis.UUCP>, gsarff@ssdis.UUCP (gary sarff) says: > Summary: processes and threads > My point was that I have seen a great many > statements like "unix processes are heavy, amiga's processes are light so > ours are better". I was just making the point that threads buy you little > "lightness" if there is only one process per thread. But Amiga processes are always lighter than those on UNIX; they're basically always threads. Even if I'm not running multiple execution paths in any single program, as long as I'm running multiple programs, I get the advantage of a much faster context switch. Since it's impossible to run an Amiga or, I suspect, UNIX, with only one unit of execution, Amiga's always going to win doing the same kinds of things. Since we now have UNIX and AmigaOS running on exactly the same piece of hardware, that's a little easier to see for real instead of theory. Under other conditions, I see the point you wanted to make. Take something like a UNIX process (a heavy process, that needs to swap MMU state for every context switch), and allow multiple threads to run within the state space of that process. The thread need only a subset of the full process overhead -- it runs in the same address space, etc. This kind of thread is only a CPU overhead win if you're running a multi-threaded application. Now you take away the underlying UNIX process, and you probably wind up with something that looks like an Amiga task or process. > Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
peter@sugar.UUCP (Peter da Silva) (06/30/88)
In article <4135@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > We're not talking a professional Unix here. Oh. I'm sorry. I thought we were... > Commodore has made no mention of Un*x on a 68000 amiga, has it? No, but then Commodore is not the only company developing professional software for the Amiga. > We're just talking how one would go about porting something like Minix > to the amiga. Why? The Amiga system software is in most areas far superior to Minix. The only thing Minix has that I really miss is the ability to easily port UNIX code to it. The only feature of UNIX that Minix supports and can't be easily emulated on the Amiga is the fork system call. So, if AmUnix doesn't support fork, what's the point? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
egranthm@jackson.UUCP (Ewan Grantham) (06/30/88)
In article <2222@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > Why? The Amiga system software is in most areas far superior to Minix. > The only thing Minix has that I really miss is the ability to easily > port UNIX code to it. So, does this mean that using minix one could easily port something like netnews, or are we talking being easier to rewrite programs that will then croak along for awhile? Seems to me that simply supporting the fork function would not be enough to make it "easy" to port code, but then maybe it depends on your definition of easy. -- Ewan Grantham (601) 354-6454 ext.358 ...!uunet!nuchat!amyerg!egranthm or {pyramid or bellcore or tness..}!swbatl!jackson!egranthm I'm not responsible for my bosses, and vice-versa
jesup@cbmvax.UUCP (Randell Jesup) (07/01/88)
In article <2222@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <4135@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> We're not talking a professional Unix here. > >Oh. I'm sorry. I thought we were... Well, then say so. No one ever did, and the discussion started about how one would run Unix/implement fork() on a 68000 w/o MMU. >> Commodore has made no mention of Un*x on a 68000 amiga, has it? > >No, but then Commodore is not the only company developing professional >software for the Amiga. It seems the only other company I have heard of that was talking about doing Un*x for the Amiga (Amnix, I forget the companies name) supposedly is no longer answering their phone. >> We're just talking how one would go about porting something like Minix >> to the amiga. > >Why? The Amiga system software is in most areas far superior to Minix. >The only thing Minix has that I really miss is the ability to easily >port UNIX code to it. The only feature of UNIX that Minix supports and >can't be easily emulated on the Amiga is the fork system call. So, if AmUnix >doesn't support fork, what's the point? Why do you think the Amiga-minix mailing list died? Because it was a LOT of work (given the state of the minix code), and in many ways minix was less sophisticated (no queuing of messages, for example). fork() was implemented by the ST-Minix people, and apparently it works pretty well (this is the copy data/stack version, I believe). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.UUCP (Peter da Silva) (07/01/88)
In article <266@jackson.UUCP>, egranthm@jackson.UUCP (Ewan Grantham) writes: > In article <2222@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > Why? The Amiga system software is in most areas far superior to Minix. > > The only thing Minix has that I really miss is the ability to easily > > port UNIX code to it. > So, does this mean that using minix one could easily port something like > netnews, or are we talking being easier to rewrite programs that will > then croak along for awhile? Easy is a relative term. I could consider porting netnews to Minix, starting with the distribution and providing stubs for the functions that are missing. I have some of them already. It probably wouldn't be much harder than porting it to a wildly variant Xenix. That, I've done. Of course, Minix doesn't have uucp or even (at the time I last looked at it) a functional serial driver, so you probably wouldn't be able to do much with it. But you could port the code. I could probably port Netnews to AmigaDOS, but there is so much more that would have to be done to make it work. I'm certainly not planning on doing it in the immediate future. > Seems to me that simply supporting the fork function would not be enough > to make it "easy" to port code, but then maybe it depends on your > definition of easy. Supporting the fork function allows you to build a UNIX compatibility box around the code, so you could run it without patching it. At the most you might need to add some includes and defines. If you don't have the fork function it's just not possible, since you can't emulate it with a spawn. Individual programs might run, but in general it would be incomplete. You can emulate system(), and you can emulate some of the uses of fork() when followed by exec(). But you can't get all of them... you'd have to dig into the code. There are two ways of emulating fork on a 68000. You can do what Minix on the ST does and copy the data segment in and out, or you can use a base register for the data segment and pretend you're an IBM-PC. Anyway, this is turning into a bit of a JJ. Let's get back to the point... what's the advantage to Minix (or something similar) on the Amiga, other than its UNIX-compatibility? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
michael@stb.UUCP (Michael) (07/02/88)
In article <4109@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <142@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: >>Threads are like shared libraries in the sense that they give you an >>advantage if you have more than 1 process using them. A shared library >> ... >>Only if the process is really executing multiple threads of itself do you get >>any advantage at all. > > This sounds an awful lot like copy-on-write in software. What happens >if one of the threads does an exec()? > >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup Hang on. Multiple threads in a process are just that--multiple execution points in a single process. Shared data segment. Shared file discriptors. Shared everything. Think of it like co-routines. I have no idea what happens on an exec(); my guess is that the entire process (and all of its threads) go away. (Want to think of the bizarre? Copy on write with multiple threads, each of which might do a fork().) : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : What would have happened if we had lost World War 2. Well, the west coast : would be owned by Japan, we would all be driving foreign cars, hmm...
peter@sugar.UUCP (Peter da Silva) (07/02/88)
In article <4159@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > Well, then say so. No one ever did, and the discussion started > about how one would run Unix/implement fork() on a 68000 w/o MMU. Well, I think we all know the two ways of doing it by now, n'est pas? > It seems the only other company I have heard of that was talking > about doing Un*x for the Amiga (Amnix, I forget the companies name) supposedly > is no longer answering their phone. I spoke to them when they were answering the phone (AMIX, Lamplighter Software, Salt Lake City UTAH). It sounded more like a UNIX compatibility library and a lot of UNIX utilities. Sort of like Unica on CP/M boxes. Anyway, it's a pity they seem to have dried up... I'd have paid good money for that. > fork() was implemented by the ST-Minix people, and apparently it works > pretty well (this is the copy data/stack version, I believe). Well, if you had to put up with ST system software, I'm sure it'd look damn good in comparison. Now then, how about XINU? Anyone done anything more than read the book? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "Running DOS on a '386 is like driving an Indy car to the Stop-N-Go"
harald@leo.UUCP ( Harald Milne) (10/15/88)
And now for something completely different.
I heard from at least 3 different sources that Amiga UNIX and
Amigados (and MSDOS) all run simultaniously on the Amiga.
Well I know Amigados and MSDOS do, but UNIX?
From reading the A500/A2000 Technical Reference Manual from CBM,
it appears that the coprocessor slot has 2 modes of DMA operation.
From what I understand, the standard 68000 AND coprocessor slot (like
CBM's A2620 68020 card with MMU) can both MASTER the bus independently.
In that case, UNIX could run side by side with Amigados, BOTH running
at the same time. They could share the same hard disk controller, (or
separate controllers). In the Zorro I expansion architecture, a coprocessor
would effectively block the standard 68000 from being a bus master at all.
But the Zorro II expansion allows BOTH to run to run at the same time.
Am I dreaming or what.
You can play games and run UNIX at the same time?
Na, I must be dreaming. I'll go back to sleep.
--
Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG)
Irvine, CA (RISCy business!)
UUCP: uunet!ccicpg!leo!haralddaveh@cbmvax.UUCP (Dave Haynie) (10/18/88)
in article <3400@leo.UUCP>, harald@leo.UUCP ( Harald Milne) says: > Keywords: Multi OS? > I heard from at least 3 different sources that Amiga UNIX and > Amigados (and MSDOS) all run simultaniously on the Amiga. > Well I know Amigados and MSDOS do, but UNIX? No. What seems to have precipitated this was the demo given by Dr. Rubin at the last Comdex. At the Commodore press conference, he was showing off some Amiga OS stuff, then clicked on the UNIX icon, and up comes UNIX. While it was explained that switching on UNIX is really a "world swap", if you see the demo, it sure enough looks like UNIX is coming up as an Amiga screen. > From reading the A500/A2000 Technical Reference Manual from CBM, > it appears that the coprocessor slot has 2 modes of DMA operation. > From what I understand, the standard 68000 AND coprocessor slot (like > CBM's A2620 68020 card with MMU) can both MASTER the bus independently. But not simultaneously. If the CPU slot device wants control of the bus, it requests the bus from the 68000, much like any expansion bus device would. In the second mode, though, it gets all expansion bus DMA requests routed to it, so it's a master fully equivalent to the 68000 in every respect. > In that case, UNIX could run side by side with Amigados, BOTH running > at the same time. They could share the same hard disk controller, (or > separate controllers). In the Zorro I expansion architecture, a coprocessor > would effectively block the standard 68000 from being a bus master at all. > But the Zorro II expansion allows BOTH to run to run at the same time. With local RAM on a CPU slot card, you could run both that card and the 68000 simultaneously. There are, however, many complexities in doing this. For instance, an interrupt comes along. Who services it, or do both CPUs try. Or if the CPU slot needs lots of chip memory access, the 68000 may never get any. The hardware protocols are there to allow two CPUs running basically at the same time, but no one's yet taken advantage of this with software. The A2620 uses this feature to optionall boot AmigaOS with the 68000 in charge, rather than the 68020. But once you're running, you're dedicated to one or the other CPU (based on the way the A2620 hardware works). > Am I dreaming or what. > You can play games and run UNIX at the same time? Not quite. Unless it's rogue or another UNIX game :-). > Na, I must be dreaming. I'll go back to sleep. If anyone wants to do a 3rd party UNIX.... > Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) > Irvine, CA (RISCy business!) > UUCP: uunet!ccicpg!leo!harald -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
paquette@cpsc.ucalgary.ca (Trevor Paquette) (12/11/88)
(Sorry if this is a repost..)
A few questions for CATS on the Unix coming out for the Amiga..
1) Does the C compiler support of the Amiga rom routines? Ie can
I open windows,, draw lines, fill polygones etc.. Or are there
whole new librarys that I have to link with?
2) VERY IMPORTANT. Does it support job control? Ie can I throw a job
into the background and then recall it later with 'fg'? Can I
suspend a job (ala '^Z') and then push it to the background?
3) Has any 4.3 BSD enhancements found it's way into it?
Trev
=============================================================================
Trevor Paquette - GraphicsLand, U of Calgary[Home of The Great Train Rubbery]
UUCP: ...!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W
Luminous beings we are, not this crude matter * I got the hippy hippy shakehbo@sbphy.ucsb.edu (Howard B. Owen) (12/12/88)
In article <312@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes... > > A few questions for CATS on the Unix coming out for the Amiga.. > > 1) Does the C compiler support of the Amiga rom routines? Ie can > 2) VERY IMPORTANT. Does it support job control? Ie can I throw a job > 3) Has any 4.3 BSD enhancements found it's way into it? All very good questions. Inquiring minds want to know. -- Howard Owen, Computer Systems Manager internet: hbo@sbphy.ucsb.edu Physics Computer Services BITNET: HBO@SBITP.BITNET University of California, Santa Barbara HEPNET/SPAN: SBPHY::HBO "I am not a pay TV service!" uucp:{The World}!ucbvax!hub!hbo
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/13/88)
In article <312@cs-spool.calgary.UUCP> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: [ about Amiga Unix ] > 1) Does the C compiler support of the Amiga rom routines? Ie can > I open windows,, draw lines, fill polygones etc.. Or are there > whole new librarys that I have to link with? Well, I suppose the compiler would let you call them if they were there, but no ROM functions (or any parts of AmigaOS) exist when Unix is running. In fact, if you even try to read the addresses where the ROM normally would be, you'll get the familiar "Bus error - core dumped". Graphics support is very simple at this point, partially because Unix doesn't do a whole lot of graphics. The windowing system can display Unix plot format files (like everybody has lots of those, eh?). > 2) VERY IMPORTANT. Does it support job control? Ie can I throw a job > into the background and then recall it later with 'fg'? Can I > suspend a job (ala '^Z') and then push it to the background? System V has this stuff called "shell layers", which, I suppose, is The Next Best Thing to Being There. Yes, you can hit ^Z, but the job is automatically "pushed into the background" (i.e. there is no "stopped" state), and you find yourself not at a shell, but at a silly prompt from which you can select which job to be active. Normally, your "jobs" are actual shell sessions, and you can have up to seven of them. Apparrently, even AT&T admits that "shell layers" is no substitute for real job control, because they will have real csh-style job control in SysV release 4, whenever that comes out (late 1989). Of course, AmigaDos doesn't have job control, either, and people get along fine without it there. (Job control is just a crutch for OS's that don't do windows. :-) > 3) Has any 4.3 BSD enhancements found it's way into it? Not really, although it is likely that some BSD command-level utilities will be included eventually. (Like csh, for example). From a programming perspective, the only BSDisms likely to be included would be a "sockets" library (and that isn't certain). -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
paquette@cpsc.ucalgary.ca (Trevor Paquette) (12/14/88)
In article <5495@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <312@cs-spool.calgary.UUCP> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > [ about Amiga Unix ] ...... > > 2) VERY IMPORTANT. Does it support job control? Ie can I throw a job > > into the background and then recall it later with 'fg'? Can I > > suspend a job (ala '^Z') and then push it to the background? > > System V has this stuff called "shell layers", which, I suppose, > is The Next Best Thing to Being There. Yes, you can hit ^Z, but ....... > Apparrently, even AT&T admits that "shell layers" is no substitute > for real job control, because they will have real csh-style job > control in SysV release 4, whenever that comes out (late 1989). > When it is released what will the update policy be for it? (Read: will it be available on the Amiga?) I work on Sun workstations all the time and even though they are windowed (which I might add I think is the best developement envirionment around) I still find myself throwing jobs in the background, bringing them back.. excuting more jobs in the same window.. etc.. I find it hard to believe that so many people out there can do without a multi-tasking/processing environment. ============================================================================= Trevor Paquette - GraphicsLand, U of Calgary[Home of The Great Train Rubbery] UUCP: ...!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W Luminous beings we are, not this crude matter * I got the hippy hippy shake
pnelson@antares.UUCP (Phil Nelson) (12/14/88)
In article <5495@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >Of course, AmigaDos doesn't have job control, either, and people >get along fine without it there. (Job control is just a crutch >for OS's that don't do windows. :-) > Even with the ability to open a 2nd shell, there are times when I ^C a job in order to restart in the background. It would sure be nice to have just enough stuff to let me use some special char to kick a running job into the background from the CLI (shell). I suppose this is difficult... -- Phil Nelson at (but not speaking for) Tymnet, McDonnell Douglas Network Systems Company POTS:408-922-7508 UUCP:{ames|pyramid}oliveb!tymix!antares!pnelson LRV: Component Station
scotty@ziggy.UUCP (Scott Drysdale) (12/15/88)
>Even with the ability to open a 2nd shell, there are times when I ^C a job >in order to restart in the background. It would sure be nice to have just >enough stuff to let me use some special char to kick a running job into the >background from the CLI (shell). I suppose this is difficult... > get PopCLI and press left-amiga-ESC and get another cli. then shrink the window you left running down somewhat if it's in the way - better yet, if you have enough chip ram free, use VBench which makes a superbitmap window out of the workbench and slide the window offscreen into a corner and check on it periodically. >Phil Nelson at (but not speaking for) --Scotty
gmd@sirius.UUCP (George MacDonald) (12/18/88)
> > Graphics support is very simple at this point, partially because Unix > doesn't do a whole lot of graphics. The windowing system can display > Unix plot format files (like everybody has lots of those, eh?). > Could the amiga's graphics be made available via a device driver? This would at least give UNIX some of the amigas power graphics! On a similar vein, why choose a yet another proprietary windowing system(YAPWS), why not X, or NeWS or display postscript? Of course with some reasonable graphic primitives these could be added later! > > 2) VERY IMPORTANT. Does it support job control? Ie can I throw a job > > into the background and then recall it later with 'fg'? Can I > > suspend a job (ala '^Z') and then push it to the background? > [Comment on the awkwardness of using shell layers and promise of better things to come. - removed ] There is a terrific program called 'screen' which allows "multi-sessions" to be done using terminals. This program relies on the BSD psuedo-tty's. Are psuedo tty's going to be in CA-UNIX? Maybe these could be emulated using streams? Most people who use system V at AT&T use the ksh(Korn shell) this has all the facilities of the csh, including job control, history, aliases built in functions etc. It is also fully upwards compatible with the bourne shell. Ksh incorporates two styles of command line editing, 'vi' style of 'emacs' style. This makes it a lot easier to edit commands than the csh ^this^forthat^ mechanism. The ksh is avaiable as a product from the AT&T toolchest and from other vendors. I have used the ksh on uVAX II's, convergent mini-frames, GOULD powernodes and SUN's each of which was running a different combinations of system V and/or Berkley UNIX's. I heard a roomer that ksh was going to be in System Vr4 but don't know for sure. All I can say to that is it's ABOUT TIME!!! Ksh has been arround since V.2 days! Anyhow Commodore could you perhaps bundle the ksh to your version of UNIX? It would reduce the need to add a csh and you may be getting a jump on the future. If not could you find someone to port it and sell it(I volunteer)? > > > 3) Has any 4.3 BSD enhancements found it's way into it? > > Not really, although it is likely that some BSD command-level > utilities will be included eventually. (Like csh, for example). > From a programming perspective, the only BSDisms likely to be > included would be a "sockets" library (and that isn't certain). Sockets would be nice, but how useful would they be without an ethernet board? I guess it would be another way to do IPC, instead of using System V message queues. B.T.W. Will Shared memory, message queues, semaphore's be supported? Do any of the beta testers reside on the net? If so it would be interesting to here your *positive* comments. Any further word on release dates? -- George MacDonald @ Northern Telecom ..!dartvax!sirius!gmd
brianm@sco.COM (Brian Moffet) (12/21/88)
In article <323@cs-spool.calgary.UUCP> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: -In article <5495@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: -> In article <312@cs-spool.calgary.UUCP> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: -> [ about Amiga Unix ] - ...... -> > 2) VERY IMPORTANT. Does it support job control? Ie can I throw a job -> -> System V has this stuff called "shell layers", which, I suppose, -> is The Next Best Thing to Being There. Yes, you can hit ^Z, but - - When it is released what will the update policy be for it? (Read: will -it be available on the Amiga?) One thing to note. If the Unix which will be on the may will be POSIX conformant, then it just might have real Job Control. Take a look at POSIX spec 1003.1. There is a section on Job control. Just a minute, I'll check if it is mandatory.... Sorry, only optional per 2.3. However, this is one of the good things about POSIX, so maybe, just maybe, they'll get it in. brian moffet -- Brian Moffet {uunet,decvax!microsoft,ucscc}!sco!brianm -or- ...sco!alar!brian "Evil Geniuses for a better tomorrow!" My fish and company have policies. I have opinions.
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/22/88)
In article <437@sirius.UUCP> gmd@sirius.UUCP (George MacDonald) writes: > Could the amiga's graphics be made available via a device driver? Graphics will be available this way, but don't be expecting graphics.library or intuition. :-| >On a similar vein, why choose a yet another proprietary windowing system(YAPWS), >why not X, or NeWS or display postscript? Of course with some reasonable >graphic primitives these could be added later! The current (proprietary) windowing system is specifically designed for the Amiga graphics hardware, and is much faster than X could be, for example. There is support for adding other display systems, and all of your suggestions are quite possible. >Are psuedo tty's going to be in CA-UNIX? Maybe these could be emulated >using streams? There is a real pseudo tty driver included. They can't easily be implemented with streams yet because AT&T hasn't released their streams version of the tty driver. >Anyhow Commodore could you perhaps bundle the ksh to your version of UNIX? Since I prefer ksh over anything, I am pushing for this. (Yes, It is part of SysVr4, but that's about a year away.) >Sockets would be nice, but how useful would they be without an ethernet >board? Not very. So get an ethernet board. (I'm not sure yet whether we will provide drivers for the Ameristar board, but I'm sure someone will.) >Will Shared memory, message queues, semaphore's be supported? Of course. >Do any of the beta testers reside on the net? If so it would be interesting >to here your *positive* comments. It would be interesting to hear negative comments, too (in the interest of eliminating them). -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
rlcarr@athena.mit.edu (Rich Carreiro) (05/03/89)
What is the current status of CBM's Amiga UNIX (AMIX?) ? Some people up here are telling me that it's fallen through? Is this true? I don't remember seeing anything on the net about it if it has. Has there been an offical announcement and/or shipping date? Thanks, ARPA: rlcarr@athena.mit.edu UUCP: ...!mit-eddie!mit-athena!rlcarr BITNET: rlcarr%athena.mit.edu@MITVMA.mit.edu ******************************************************************************* * Rich Carreiro "I will get by. I will get by. I will get by-y-y. * * rlcarr@athena.mit.edu I will survive." -- the Grateful Dead * *******************************************************************************
alh@hprmokg.HP.COM (Al Harrington) (05/05/89)
On another Unix note, I asked Andy Tanenbaum if there was an Amiga port of Minix. He said there was but neither Prentice Hall or CBM wants to sell it! He said he is looking for a third party vendor. If he can't find someone to sell it they'll toss it!! Any third party vendors out there that want to sell it???? Minix is a Unix that Andy wrote for the IBM -- his OS book includes the full source listing. It would be quite nice on the Amiga. +-----------------------------------------+---------------------------------+ | -Al Harrington //// | Instant Guru BBS | | ________ //// | (916) 488-9278 | | |__/\__| \\\\ //// | 120 Megs - All Amiga! | | \\\X/// | Over 1000 files online | | alh@hprmo.HP.COM \XXX/ | Baud: 1200/2400 Hours: 24 | | ..{hplabs,hp-sde}!hprmo!alh | PCPursuit: CASAC 1200/2400 | +-----------------------------------------+---------------------------------+ | My comments in no way reflect the views or opinions of Hewlett-Packard | +---------------------------------------------------------------------------+
bakken@arizona.edu (Dave Bakken) (05/08/89)
In article <13240027@hprmokg.HP.COM>, alh@hprmokg.HP.COM (Al Harrington) writes: > [etc. ] It would be quite nice on the Amiga. > It would be great to tinker with. But MINIX is not a production UN*X - it was designed to be a teaching tool and was shaved down to be able to run on IBM floppies (this was considered important, so as not to price out students). -- Dave Bakken bakken@arizona.edu uunet!arizona!bakken
dlarson@blake.acs.washington.edu (Dale Larson) (02/14/90)
<eat me>
I'd love to hear from someone at C/A or someone otherwise in the know about
what is available and for how much in terms of UNIX on the Amiga.
I know that unix on the amiga isn't vaporware, but it is also not generally
available. I now need a unix box which can run the most current version
of Open Look. If I can get such a thing through C/A as a developer now
(I am not currently part of certified developer program, but could join
again), can I get such a box from C/A tommorow (or next week?)? Is there
any chance that I can get such a box as a member of the public within the next
two months? If not, it's going to have to be a NeXT or a Sun for me,
neat educational discount for Amiga's aside!
Thank you for responding via email.
--
There are two ways to improve on human factors in computing:
Make the programmers less stupid and/or make the users less stupid.
Both are necessary, neither are likely.
-Digital Teddy Bear (dlarson@blake.acs.washington.edu)guest@hpdmd48.boi.hp.com (Guest) (08/07/90)
When is Commodore planning on releasing their Amiga Unix in the US? I have been waiting patiently for it...and I have never heard anything... Also, what form of system will be required to hold this UNIX? (i.e. min Hard Drive space, memory, etc.) And how does this UNIX supposedly hold up against other forms of UNIX out on the Market? How much will this UNIX cost? lukes@hpdml80.boi.hp.com
jet@karazm.math.uh.edu (J. Eric Townsend) (08/08/90)
In article <15440027@hpdmd48.boi.hp.com> guest@hpdmd48.boi.hp.com (Guest) writes: >When is Commodore planning on releasing their Amiga Unix in the US? I >have been waiting patiently for it...and I have never heard anything... There's supposed to be a demo of Amiga UNIX in Houston sometime in late August, but I think it's a closed demo for NASA and some of its contractors. (I'm doing my best to get into it, however, since I work for major university and am involved in purchasing. :-) -- J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120 Internet: jet@uh.edu Bitnet: jet@UHOU Skate UNIX(r)
tyager@maxx.UUCP (Tom Yager) (08/10/90)
In article <1990Aug7.183454.20283@lavaca.uh.edu>, jet@karazm.math.uh.edu (J. Eric Townsend) writes: > In article <15440027@hpdmd48.boi.hp.com> guest@hpdmd48.boi.hp.com (Guest) writes: > >When is Commodore planning on releasing their Amiga Unix in the US? I > >have been waiting patiently for it...and I have never heard anything... > > There's supposed to be a demo of Amiga UNIX in Houston sometime > in late August, but I think it's a closed demo for NASA and some of > its contractors. (I'm doing my best to get into it, however, since > I work for major university and am involved in purchasing. :-) > J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120 > Internet: jet@uh.edu At the recent Usenix show in Anaheim, AT&T (of all people!) was showing the new System V, release 4 on an Amiga 3000. The flack in the booth had no idea how it was configured, but it was running. Apparently, the port takes some advantage of the blitter because part of the demo was the image of an airplane flying across an X window. It wasn't zippy, but much faster than I would have expected for a little '030. Yep, there were lots of windows, and I was even allowed to type a few commands into the Korn shell (or was it a POSIX shell?). It sure looked like UNIX. AT&T expects that Commodore will be one of the first, if not THE first hardware manufacturer to produce a commercial release of V.4. That OS is already shipping (to developers only, at a price of over $2000), but is reportedly in a fragile state. Widespread commercial distribution of V.4 to "reg'lar folks" is expected in November from Intel, among others. If AT&T is right about Commodore's effort being so much further along, perhaps we'll see something from them before that? That having been said, I have one question which I hope won't piss anyone off unduly: Why would you want to run UNIX on an Amiga? I'm not being critical, mind you, and I haven't chosen sides. I'd just like to hear from some of you what you feel the Amiga has to offer a UNIX user that you can't get from one of the $5000 boxes from Sun or Apollo/HP. If the initial release allows you to mix AmigaDOS and UNIX programs on the same box and screen, then that's something, and my question is pointless. Failing that, what are some of the other reasons for running UNIX on an Amiga? (ty) -- +--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ | UUCP: decvax!maxx!tyager NET: maxx!tyager@bytepb.byte.com | | "I just bought...the Macintosh portable. And I took it back. Pain in the | +--butt." --Harry Connick, Jr.-------I speak only for myself.--------------+
swarren@convex.com (Steve Warren) (08/10/90)
In article <77@maxx.UUCP> tyager@maxx.UUCP (Tom Yager) writes: [...] >That having been said, I have one question which I hope won't piss anyone >off unduly: Why would you want to run UNIX on an Amiga? I'm not being >critical, mind you, and I haven't chosen sides. I'd just like to hear from >some of you what you feel the Amiga has to offer a UNIX user that you can't >get from one of the $5000 boxes from Sun or Apollo/HP. If the initial release >allows you to mix AmigaDOS and UNIX programs on the same box and screen, >then that's something, and my question is pointless. Failing that, what are >some of the other reasons for running UNIX on an Amiga? [...] On my own time I am first an Amiga user. I own an Amiga for its video capabilities and entertainment value. The Amiga fills my idea of entertainment better than anything else out there. Now because of the amount of discretionary time that I spend on my Amiga, I am very familiar with it and with the applications that I use on it. My Amiga could be extremely useful to me in my work because of my familiarity with the tools and applications. But at work we use Unix workstations on an Ethernet network. It is not convenient to keep a workstation and my Amiga there on my desk together. If I have to reboot then that is a drawback. However, I've still multiplied the capabilities of my box. There just don't seem to be many easy-to-use applications available for Unix boxes beyond the few specialized applications that the boxes were purchased for (ie board routing or cad or whatever). A Unix box that is also capable of using Amiga applications (which I am already familiar with) is superior to one that does not have this capability. -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. Warren v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.COM
jerry@truevision.com (Jerry Thompson) (08/10/90)
Reason #1: I already have an Amiga and I don't want to buy another computer
just to run Unix.jjfeiler@arrester.caltech.edu (John Jay Feiler) (08/11/90)
tyager@maxx.UUCP (Tom Yager) writes: >That having been said, I have one question which I hope won't piss anyone >off unduly: Why would you want to run UNIX on an Amiga? I'm not being >critical, mind you, and I haven't chosen sides. I'd just like to hear from >some of you what you feel the Amiga has to offer a UNIX user that you can't >get from one of the $5000 boxes from Sun or Apollo/HP. If the initial release >allows you to mix AmigaDOS and UNIX programs on the same box and screen, >then that's something, and my question is pointless. Failing that, what are >some of the other reasons for running UNIX on an Amiga? >+--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ I want Unix on my amiga for one very important reason ... I don't have the cash to buy an A3000 and a $5000 box from sun or apollo. There's a lot of PD/FR software out there that I can't be bothered to port to AmigaDOS, but would still like to run at home. But I won't pay $5000 for a diskless Sun, or Apollo, because then my current software investment wouldn't be usable on my new machine. Having an A3000 with Unix is the best of all possible worlds as far as I'm concerned..... (except for that laptop Cray Y-MP I've got on order :-) John Feiler
es1@cunixb.cc.columbia.edu (Ethan Solomita) (08/11/90)
>That having been said, I have one question which I hope won't piss anyone >off unduly: Why would you want to run UNIX on an Amiga? I'm not being >critical, mind you, and I haven't chosen sides. I'd just like to hear from >some of you what you feel the Amiga has to offer a UNIX user that you can't >get from one of the $5000 boxes from Sun or Apollo/HP. If the initial release >allows you to mix AmigaDOS and UNIX programs on the same box and screen, >then that's something, and my question is pointless. Failing that, what are >some of the other reasons for running UNIX on an Amiga? >+--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ The $5,000 SparcStation SLC is a very nice machine. However, it has no harddrive. Now that's no problem if you are hooked up to a network with a big drive, but as a standalone machine you have to buy an external SCSI drive. The SLC is black&white, the new color sun being $10,000. There is a disadvantage. Although you can't get both Amiga and Unix simultaneously, you can boot either way. Commodore has also hinted at the possibility of such a combo in the future. -- Ethan Ethan Solomita: es1@cunixb.cc.columbia.edu "If Commodore had to market sushi they'd call it `raw cold fish'" -- The Bandito, inevitably stolen from someone else
ag@cbmvax.commodore.com (Keith Gabryelski) (08/11/90)
In article <77@maxx.UUCP> tyager@maxx.UUCP (Tom Yager) writes: >At the recent Usenix show in Anaheim, AT&T (of all people!) was >showing the new System V, release 4 on an Amiga 3000. Commdore was in AT&T's booth at the request of AT&T. >Apparently, the port takes some advantage of the blitter because part >of the demo was the image of an airplane flying across an X window. Interesting, I thought it was a train. The blitter was not used in that demo. Pax, Keith
telam@pyrps5 (Thomas Elam) (08/17/90)
In article <77@maxx.UUCP> tyager@maxx.UUCP (Tom Yager) writes: > >AT&T expects that Commodore will be one of the first, if not THE first >hardware manufacturer to produce a commercial release of V.4. That OS is >already shipping (to developers only, at a price of over $2000), but is >reportedly in a fragile state. > >Widespread commercial distribution of V.4 to "reg'lar folks" is expected in >November from Intel, among others. If AT&T is right about Commodore's effort >being so much further along, perhaps we'll see something from them before >that? > >That having been said, I have one question which I hope won't piss anyone >off unduly: Why would you want to run UNIX on an Amiga? I'm not being >critical, mind you, and I haven't chosen sides. I'd just like to hear from >some of you what you feel the Amiga has to offer a UNIX user that you can't >get from one of the $5000 boxes from Sun or Apollo/HP. If the initial release >allows you to mix AmigaDOS and UNIX programs on the same box and screen, >then that's something, and my question is pointless. Failing that, what are >some of the other reasons for running UNIX on an Amiga? > >+--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ >| UUCP: decvax!maxx!tyager NET: maxx!tyager@bytepb.byte.com | >| "I just bought...the Macintosh portable. And I took it back. Pain in the | >+--butt." --Harry Connick, Jr.-------I speak only for myself.--------------+ I don't consider myself an expert, but I, for one, am interested in the Amiga for its unique position, that I view as being due to at least 3 things, the last 2 of which are reasons for running UNIX on an Amiga: 1) its low cost of use as a basic and powerful mass-market personal computer; 2) its video interfaces that come standard even in the low-end Amiga family member; 3) its capabilities in and support for high-speed multimedia (bit blitter, graphics coprocessor, sound coprocessor, sound waveform generators (?), bunch of DMA channels; animation, 4-channel stereo sound; serial port, parallel port, SCSI, etc.--someone please jump in if I missed some important things!). I would be accomplishing a lot more programming on my Amiga if things like csh and make worked the way I'm used to. That's not to say programming on an Amiga generally goes slowly. I just like to do my learning gradually. I like to get some quick results, based on the UNIX experience I've spent so much time building up. Tom Elam - My opinions do not necessarily represent the opinions of my company. -
mdw6432@acf5.NYU.EDU (mdw6432) (09/23/90)
Any idea how much Amiga UNIX will cost? Also, are there any beta testers out there who can give their first impressions? If its b eing endorsed by a college and bought by the gov't, I assume it must be fairly reliable. Mark Wolfskehl mdw6432@acf5.nyu.edu
mrush@csuchico.edu (Matt "C P." Rush) (09/24/90)
In article <1238@acf5.NYU.EDU> mdw6432@acf5.NYU.EDU (mdw6432) writes: >Any idea how much Amiga UNIX will cost? Also, are there any beta testers out Also, how is it going to be DISTRIBUTED (tape, floppy, etc.) and what additional hardware is required (besides an A2620/30 or A3000) to run it? >there who can give their first impressions? If its b eing endorsed by a >college and bought by the gov't, I assume it must be fairly reliable. I don't think anybody is actually "endorsing" this product (Bo knows UNIX :-). Besides, 'reliable' and UNIX are fairly mutually exclusive concepts. >Mark Wolfskehl >mdw6432@acf5.nyu.edu -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "I programmed three days % Beam me up, Scotty. % % And heard no human voices. % There's no Artificial % % But the hard disk sang." % Intelligence down here. % % -- Yoshiko % % E-mail: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
jet@karazm.math.uh.edu (J. Eric Townsend) (09/24/90)
In article <1990Sep23.200522.29223@ecst.csuchico.edu> mrush@cscihp.UUCP writes: > Also, how is it going to be DISTRIBUTED (tape, floppy, etc.) and what >additional hardware is required (besides an A2620/30 or A3000) to run it? Why couldn't it run on an A2000HD? Or an A2000, for that matter. Most miniroots for "real" unix machines are under 800K, that leaves you with another floppy for everything else. :-) -- J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120 Internet: jet@uh.edu Bitnet: jet@UHOU Skate UNIX(r)
griffith@eecs.cs.pdx.edu (Michael Griffith) (09/24/90)
jet@karazm.math.uh.edu (J. Eric Townsend) writes: >In article <1990Sep23.200522.29223@ecst.csuchico.edu> mrush@cscihp.UUCP writes: >> Also, how is it going to be DISTRIBUTED (tape, floppy, etc.) and what >>additional hardware is required (besides an A2620/30 or A3000) to run it? >Why couldn't it run on an A2000HD? Or an A2000, for that matter. >Most miniroots for "real" unix machines are under 800K, that leaves >you with another floppy for everything else. :-) It will almost definitely need a 68020 with MMU or a 68030 (built-in MMU) to provide memory protection and virtual memory. >-- >J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120 >Internet: jet@uh.edu >Bitnet: jet@UHOU >Skate UNIX(r) | Michael Griffith | If I had an opinion it certainly | | griffith@eecs.ee.pdx.edu | wouldn't be the same one as | | ...!tektronix!psueea!eecs!griffith | Portland State University anyways. |
d87-khd@sm.luth.se (Karl-Gunnar Hultland) (09/24/90)
In article <1990Sep24.003956.23964@lavaca.uh.edu> jet@karazm.math.uh.edu (J. Eric Townsend) writes: >In article <1990Sep23.200522.29223@ecst.csuchico.edu> mrush@cscihp.UUCP writes: >> Also, how is it going to be DISTRIBUTED (tape, floppy, etc.) and what >>additional hardware is required (besides an A2620/30 or A3000) to run it? > >Why couldn't it run on an A2000HD? Or an A2000, for that matter. >Most miniroots for "real" unix machines are under 800K, that leaves >you with another floppy for everything else. :-) > There's one quick answer to that question, in fact I can answer it with one word. MMU The 2000(HD) doesn't have it. Karl --- Karl Hultland,(d87-khd@sm.luth.se) University of Lulea,Sweden Egoist: a person of low taste, more interested in himself than in me. - A. Bierce
jet@karazm.math.uh.edu (J. Eric Townsend) (09/25/90)
In article <1990Sep24.003956.23964@lavaca.uh.edu> I wrote: >In article <1990Sep23.200522.29223@ecst.csuchico.edu> mrush@cscihp.UUCP writes: >> Also, how is it going to be DISTRIBUTED (tape, floppy, etc.) and what >>additional hardware is required (besides an A2620/30 or A3000) to run it? >Why couldn't it run on an A2000HD? Or an A2000, for that matter. Oh duh. I forgot. No MMU. As for all of the "a 68000 isn't fast enough for UNIX" replies, I've used plenty of 68000 based UNIX machines, so it is possible. Hell, I've two-user pre-emptive multitasked on a 6809 running at 1Mhz. It *is* possible to multitask on a slow chip. It's just painful sometimes. -- J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120 Internet: jet@uh.edu Bitnet: jet@UHOU Skate UNIX(r)
lupe@alanya.Germany.Sun.COM (Lupe Christoph - Sun Germany Consulting - Munich) (09/26/90)
mrush@csuchico.edu (Matt "C P." Rush) writes: > I don't think anybody is actually "endorsing" this product (Bo knows >UNIX :-). Besides, 'reliable' and UNIX are fairly mutually exclusive concepts. Want a flame war ? OK, OK, I'll keep it short. Just one tiny little SPARC ;-) Suppose you had an operating system that did *not* need to reboot every time a stupid application program did something wrong ? Fizzle ... -- | lchristoph@Sun.COM (Internet) | Disclaimer: | | ...!unido!sunmuc!lupe (German EUNet, "bang") | My employer has a | | lupe@sunmuc.UUCP (German EUNet, domain) | non-exclusive license | | ...!suninfo!lchristoph (Sun Germany customers) | to my opinion. |
new@ee.udel.edu (Darren New) (09/26/90)
In article <lupe.654297359@alanya> lupe@alanya.Germany.Sun.COM (Lupe Christoph - Sun Germany Consulting - Munich) writes: >Suppose you had an operating system [like UNIX] that did *not* need to reboot every >time a stupid application program did something wrong ? Actually, I refer you to the well-known "portmapper" bug (which causes the portmapper to exit), the MMDF bug (which causes mailboxes to remain locked indefinitely), and the "lpr" bug (documented below from the man page) all of which is software *that comes with the OS*!!! Don't act like there are no problems that need rebooting or very arcane knowledge in Unix. It just ain't so. -- Darren > lpr: printer: jobs queued, but cannot start daemon. > The connection to lpd on the local machine failed. > This usually means the printer server started at boot > time has died or is hung. Check the local socket > /dev/printer to be sure it still exists (if it does not > exist, there is no lpd process running). -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee -----
seanc@pro-party.cts.com (Sean Cunningham) (09/26/90)
In-Reply-To: message from jet@karazm.math.uh.edu Probubly because you'll need either a 68851MMU or the one integral in the 68030 for Amiga Unix to work...virtual memory. Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
peter@sugar.hackercorp.com (Peter da Silva) (10/07/90)
In article <31557@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: > Actually, I refer you to [a bunch of BSD bugs] A. BSD is known to be buggier than a dog pound. System V is really more robust... and that's what Amiga UNIX is based on. B. Notice that none of the bugs you listed involve rebooting the machine to correct them. There's a big difference between temporarily having a mailbox locked and dumping the whole system and anything you're working on. We have 40 Xenix boxes running on 80286es (well, 386es in 286 mode). This Xenix is System III based, and is buggier than BSD. And yet we have very few crashes... most of which are due to a known bug in a no longer supported device driver. Third party buggy software, in other words. We only have to worry about device drivers. On the Amiga all software is dangerous. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
joseph@valnet.UUCP (Joseph P. Hillenburg) (10/08/90)
I heard that the new version of UNIX V.4 is where V.4 and BSD merge. Just providing a little info. -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
tjhayko@THUNDER.LAKEHEADU.CA (10/26/90)
Ok, there seems to be a lot of discussion on the net about the new version of Un
now available for Amigas (or about to be available). My question is:
What kind of hardware do I have to have to run Amiga Unix on my B2000?
*************************************************************
* Tom Hayko * only the Amiga /// *
* tjhayko@thunder.lakeheadu.ca * (Commodore is starting/// *
* * to know that) \\\/// *
* * and it's about time\XX/ *
*************************************************************
QUITakcs.darkelf@ddsw1.MCS.COM (Noam Ben Ami) (05/26/91)
Dateline:Multi Electronic Data Services Incorporated.... We at MEDS Inc. are now authorized to sell Amiga Unix machines! These A3000 workstations come with: Unix SVR4 X windows Open Look software Plus much more software Hardware (for A3000UXD)... 68030 running at 25MHz 68882 running at 25MHz 200megabyte harddrive 9 megabytes of memory (2megs video ram) Ethernet port 2 video ports:Analog/RGB SCSI port 68040 slot Much much more... Support (from MEDS)... A total commitment to our customers! Sound interesting? Give us a call at (708)-424-0212 Or, call our BBSs at (708)-982-1123