mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) (05/27/87)
In article <3708@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >In article <159@tahoma.ARPA> bakken@tahoma.ARPA (Dave Bakken) writes: ><I bought my Amiga in December of '85, and I chose it over the Atari ><because it was (and still is) the only PC to offer true multitasking. > >Horsefeathers. OS/9 has been available on a fair number of machines >for years, and it has true multitasking. >It's been at least three years since Radio Shack starting selling OS/9 >for the Color Computer (I started 32 shells on one once, just to see >how it would run. Not bad...). With the introduction of the CoCo III >last year, Tandy announced only OS/9 for an OS. They also put in an >MMU. With the release of OS/9 level II early this year, you got a >windowing system, as well. > <mike I've been involved with the CoCo for over five years. Since the Atari ST and the Amiga have been released, I've purchased both, and sold my CoCo. True, the CoCo runs OS-9. I work at Computeware and we had Level 2 and CoCo 3's before almost anyone. This machine is a dog. I would hardly call the CoCo 3's "Data Address Translator" a MMU in any but the most primitive sense of the word. The windowing system Mike mentions, called "Multi-View", is NOT out yet, and Tandy has yet to announce when, if ever, this will be released. Graphics primitives are present in the Level 2 package, but the operating system barely uses them at all. When you get a chance, visit comp.sys.m6809, the newsgroup for the CoCo. Besides the fact that there's only 2-3 messages a day, you will notice all they ever talk about is the bugs in OS-9. Without going into further detail, I can assure everyone the CoCo is a computer from the past, and either an ST or Amiga is far superior. Even as far as price, the CoCo can not compete! Going by standard prices today, a CoCo with 512K, one drive, and a RGB monitor lists for $219+149+299+299= $950. With a similar 520 ST costing about $799, and an Amiga 500 (or discounted 1000) costing $950, there's no reason to buy a CoCo. The CoCo was a great machine in its day (1981 ~ 1985), I know, but it just doesn't cut it today. -- Stephen Hartford, programmer (a.k.a. student) /// -- \\\/// Internet: mu106sbn%sdcc13@sdcsvax.ucsd.edu \/// UUCP: ...!sdcsvax!sdcc13!mu106sbn
knudsen@ihwpt.UUCP (05/29/87)
In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: > Since the Atari ST and the Amiga have been released, > I've purchased both. Must be nice to be single with no kids. Some of us have to think bang per buck, or maybe just bucks. If I were starting from scratch, I'd get a mono 520 ST, but see below... > I would hardly call the CoCo 3's "Data Address Translator" a > MMU in any but the most primitive sense of the word. Better primitive than non-existant, which describes the MMUs on the Big A machines. Amiga's memory usage is a family embarrassment. I recall a posting by an Amiga user who found her AMiga used up 512K RAM faster for the same functions than OS9 on a 64K Coco! > When you > get a chance, visit comp.sys.m6809, the newsgroup for the CoCo. > Besides the fact that there's only 2-3 messages a day, you will Cuz we can play with our Cocos for days without finding any new bugs to post about... > notice all they ever talk about is the bugs in OS-9. Not "all." Funny you missed how they're still talking about the 40-folder bug in TOS, tho they've figured out how to mix single- and double-sided disk drives (which we Coconuts did two years earlier). I read the Amiga group in the early days, and it was nothing but guru meditation numbers (crashes) and who can-or-cannot stand the flicker on the 400-line interlace. A major "bug" in OS9 windows turned out to be a manual misprint. I won't repeat the things said about Atari and Amiga documentation; I mean, this is a family group here... Let's face it, these newsgroups are like the American press, for washing dirty laundry in public. Foreigners think the USA is a terribly corrupt place, because we talk about problems openly. Should we stop talking about bugs and fixes and how our machines could be BETTER, and just start cheerleading about how great our machines are? Leave that to the ads and salesmen! > > Even as far as price, the CoCo can not compete! Going by standard > prices today, a CoCo with 512K, one drive, and a RGB monitor lists > for $219+149+299+299= $950. Try 170+80+180+260 = $690 using mail-order discount prices. Of course, for REALLY overpriced 8-bit machines, we could go over to .Apple and flame about the II-GS -- gawd what a rip! > The CoCo was a great machine in its day (1981 > ~ 1985), I know, but it just doesn't cut it today. I think what you mean, Steve, is that given the costs of keyboard, cabinet, and peripherals, it makes more sense to build a NEW system around a 68000 than any 8-bit micro. I'll agree there. But for someone already heavily invested in Coco hard/soft ware, a Coco-3 upgrade gives lots more bang/buck than any other path, and lets us develop GEM-type features. PS: I don't want to start religious wars over, but this grenade landed in my newsgroup, so I just pulled the pin and tossed it back.... -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
hah@isum.intel.com (Hans Hansen) (06/01/87)
In article <1710@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: >> Since the Atari ST and the Amiga have been released, >> I've purchased both. > > [Some totally absurd nonsense by Mike Knudson to a good comparison of 3 > computers by Stephen Hartford.] > >PS: I don't want to start religious wars over, but this >grenade landed in my newsgroup, so I just pulled the pin >and tossed it back.... >-- >Mike J Knudsen Mike, while you found it necessary to defend the honor of your PET computer. Your total ignorance of the other computers that you mention is a massive miss use of net bandwidth. I am not saying don't post, just have your facts straight before you start typing. Please E-Mail all replies to hah@intelos Hans
rca@fico2.UUCP (06/01/87)
Hans, you describe Mike Knudsen's rebuttal to Stephen Hartford's critique of the Tandy Color Computer as a "massive misuse of net bandwidth" and "totally absurd nonsense" posted to "defend the honor of (his) pet computer" out of "total ignorance" towards the Amiga and ST. Without mentioning any examples of factual errors on Mike's part to back up this assertion, you then proceed to slap his hands by suggesting he "have his facts straight" before posting again. Could you please lower the flame level? I found Stephen's critique of the Color Computer, and Mike's subsequent rebuttal, to both contain some very good points. Please note that Mike freely admits that if he were to start over, he'd get a 520 ST rather than a Color Computer since, as he put it, "it makes more sense to build a new system around a 68000 than any 8-bit micro" (such as the Color Computer). This does not sound like "defending the honor of his pet computer" to me. It sounds like a very honest and frank assessment of reality. Your reply, on the other hand, was utterly unconvincing (though I am sure it was very emotionally satisfying to type it in). Sorry, "Nyah nyah nyah nyah nyah" just doesn't cut it. This "my computer can beat up your computer" stuff is pointless, anyway. Although I normally work with a Color Computer, I also have worked with, and very much appreciate, Amigas, Macs, and ST's. They are all very fine machines, and I can easily think of applications for which I would gladly use one of them over my present machine. -- "186,000 miles per second: it's not just a good idea--IT'S THE LAW!" [ Rick Adams -- Color Central Software -- Rohnert Park, CA ] [ USENET: ...!sun!lll-crg!well!fico2!rca Delphi: RICKADAMS ]
jimomura@lsuc.UUCP (06/02/87)
In article <749@omepd> hah@isum.UUCP (Hans Hansen) writes: >In article <1710@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >>In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: >>> Since the Atari ST and the Amiga have been released, >>> I've purchased both. >> >> [Some totally absurd nonsense by Mike Knudson to a good comparison of 3 >> computers by Stephen Hartford.] Hans, it's very easy to make a great generalization like this when it suits your purpose. What exactly was "totally absurd nonsense" in what Mike wrote? Having bought an ST and had a fair bit of contact lately with the Amiga and owned a CoCo3 I can say that what Mike said was essentially correct. While the OS's of the Amiga and ST have had massive bugs, which make up the bulk of the postings in the net postings regarding those machines, the OS-9 Level II port on the CoCo is amazingly bug-free. As Mike *correctly* noted, the biggest *alleged* bugs found on the OS-9 port boiled down to vague or misleading points of documentation. That and problems arising from mixing old version hardware with new version hardware. If you have doubts of this, I have printed transcripts of almost all the postings regarding the Level II and if you care to pay for photocopies and my time ($100.00/hr.) I'll send them to you. I have not kept transcripts of the "column feet" of bug reports regarding TOS/GEM and AmigaDOS/Intuition. Mike also pointed out quite correctly, that if you want to compare *discount* prices of Amiga and ST equipment then you should compare *discount* prices of CoCo3 equipment which are proportionally lower than the list prices that Stephen pointed at. Stephen has shown that he wasn't totally conversant with the CoCo situation, but you, you've shown utterly *incredible* ignorance. Anyone who has paid reasonable attention to the postings of the 'm6809', 'amiga' and 'atari.st' newsgroups know darned well that Mike was right on these points. It's almost beyond debate. As such you didn't even bother to *try* to allege any factual basis for your posting. If you clearly don't know what you're talking about, why bother to post *anything*? Does it make you feel good? Please don't post anymore unless you have something to say worth reading. >>PS: I don't want to start religious wars over, but this >>grenade landed in my newsgroup, so I just pulled the pin >>and tossed it back.... >>-- ... >Mike, while you found it necessary to defend the honor of your PET computer. >Your total ignorance of the other computers that you mention is a massive >miss use of net bandwidth. I am not saying don't post, just have your facts As noted before, Mike easily showed more knowledge about the computers mentioned than you. >straight before you start typing. Hans, practice what you preach, and don't even bother to post. You didn't even allege any facts to have straight--totally worthless posting. >Please E-Mail all replies to hah@intelos No, I think it's worth it for people to find out what a stupid thing you have posted. Hopefully your employers don't find your day to day work as utterly worthless as your posting on this topic was. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
knudsen@ihwpt.ATT.COM (mike knudsen) (06/02/87)
In article <749@omepd>, hah@omepd.UUCP writes: > Mike, while you found it necessary to defend the honor of your PET computer. PET? Not that "pet!" Please! > Your total ignorance of the other computers that you mention is a massive > miss use of net bandwidth. I am not saying don't post, just have your facts > straight before you start typing. It was not my intention to badmouth the other machines, nor to use faulty facts. The intended IRONY of my posting was that every bad thing I said about the other machines was quoted from their newsgroups! What got my goat was the claim that "all we talk about in m6809 is bugs in OS9." When of course every newsgroup talks about bugs in their respective machines. So I reiterated the complaints that I remembered from those groups. I stand by my claim that the ST has no memory mgmt. This was beaten to death in discussing UN*X on the ST. I recall that the Amiga doesn't have MMU either. I guess Steve called the Coco's MMU "primitive" because it lacks write-protect and execute-only. True, but it still affords some protection from wayward programs--since upgrading to Level 2 OS9 I have crashed my own program to hell without always killing the OS and needing to reboot. The Amiga's multi-tasking OS insists on loading separate copies of the executable code for each process using that code, instead of sharing one re-entrant version like OS9 or UNIX. Thus memory can go away fast in an Amiga. This too, from an Amiga user in her newsgroup. That covers the only "facts" I mentioned. Help me out where I'm wrong. I don't deny the superiority of the 68K machines, or even their better bang/buck for someone starting from scratch (the new cheaper Amiga looks like a killer; the ST always has been). But just as the Apple II-GS will probably sell only to current Apple 2 owners, the Coco-3 is a very cost-effective upgrade, at least for those more interested in writing their own applications than buying off-the-shelf software. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
knudsen@ihwpt.UUCP (06/04/87)
In article <1835@lsuc.UUCP>, jimomura@lsuc.UUCP (Jim Omura) writes: > said was essentially correct. While the OS's of the > Amiga and ST have had massive bugs, which make up the > bulk of the postings in the net postings regarding those > machines, the OS-9 Level II port on the CoCo is amazingly > bug-free. I have not kept transcripts of the "column feet" of > bug reports regarding TOS/GEM and AmigaDOS/Intuition. About the bugs in the As' OSes -- I guess OS9 is relatively clean because it was around for some years before the Coco port (and Microware didn't try to rush it out at KMart prices). People probably think OS9 was written for the Coco (I've seen it referred to in consumer computer mags as "Tandy's proprietary OS"). Just like people think IBM wrote MSDOS (oops, excuse the profanity...) > Anyone who has paid reasonable > attention to the postings of the 'm6809', 'amiga' and 'atari.st' > newsgroups know darned well that Mike was right on these > points. It's almost beyond debate. > Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 > ihnp4!utzoo!lsuc!jimomura > Byte Information eXchange: jimomura Thanks for the spirited defense, Jim! Tag-team computer wars. BTW, I got a perfectly nice email response from an Amiga user to the effect that Intuition does indeed support shared libraries and routines, but you have to write them in 68K assembler; their C compiler won't make sharable code--he was rather burned up about that! I have the opposite problem--I wish I could make the Microware C put out non-sharable code, which could be much smaller in the initialized data department. Have to go to assembler to beat that. Or go to Level 2 since most of my data are graphics icons. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/04/87)
>The Amiga's multi-tasking OS insists on loading separate >copies of the executable code for each process using that >code, instead of sharing one re-entrant version like OS9 >or UNIX. Sorry, but that is not correct. Sharing one re-entrant version of code is quite easy, no insisting needed. Not all programs written for the Amiga *ARE* re-entrant (or even re-usable) simply because it's not enforced. The RESIDENT command will make a hunk of code "resident". (very obscure loader joke intended) It's not automagic, but could easily be once a special "trust me, I'm reusable and/or re-entrant" flags are added to the load format. (See previous posting in comp.sys.amiga about the RESIDENT compatible command) >--------- > Thus memory can go away fast in an Amiga. Just goes to show... if you can run 6 programs you WILL run 6 programs. For what you get memory usage is not overly high. However, consider how much memory you need just for those nice graphics screens, say 16 colors/line on a 704*464 pixel display. Or H.A.M where you get to play with any of the 4096 all on one line? An extra 1/2 - 12 megabytes is a much welcome addition to an Amiga. (Of course you could use Macintosh emulation mode and drop down to a 1 bit-plane monochrome display...)
hadeishi@husc4.UUCP (06/04/87)
In article <8706040024.AA10895@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > >>The Amiga's multi-tasking OS insists on loading separate >>copies of the executable code for each process using that >>code, instead of sharing one re-entrant version like OS9 >>or UNIX. > >Sorry, but that is not correct. >Sharing one re-entrant version of code is quite easy, no insisting needed. >Not all programs written for the Amiga *ARE* re-entrant (or even re-usable) >simply because it's not enforced. >The RESIDENT command will make a hunk of code "resident". (very obscure loader >joke intended) Actually, shared text (i.e., shared executable) is not particularly essential on a single-user machine since most processes will be different executables anyway. But the real memory hog is the UNIX machines, not the Amiga, since the Amiga has shared libraries which make executables that access shared system resources and functions (windowing interface, etc.) much smaller than their UNIX counterparts, which have to link in a HUGE run-time library to EACH executable that uses them. Thus UNIX windowing applications tend to run quickly up into the multi-megabyte range, where the equivalent Amiga executable would be MUCH smaller. Things would be even better if someone wrote a shared run-time stdio library and other Sys V function library; then multiple executables, even totally different executables would have shared text automagically. But even with only windowing and DOS functions in shared libraries the Amiga executables tend to be far smaller than their Sun (for example) counterparts. So even ignoring the "resident" command (which only works with specially prepared executables) the Amiga tends to have better memory usage than similar UNIX-based windowing systems. -Mitsu
jack@mcvax.UUCP (06/04/87)
In article <2194@husc6.UUCP> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >... But the real memory hog is the UNIX machines, not >the Amiga, since the Amiga has shared libraries which make executables >that access shared system resources and functions (windowing interface, >etc.) much smaller than their UNIX counterparts, which have to link >in a HUGE run-time library to EACH executable that uses them. Thus >UNIX windowing applications tend to run quickly up into the multi-megabyte >range, where the equivalent Amiga executable would be MUCH smaller. This might *seem* true, if you look at the sun et. al., but it isn't if you design your window manager carefully, and make the right decisions about what to put in the kernel, what to put in a system-wide daemon, and what to put in user libraries, (and what to put in hardware, if you have that option), you can end up with a powerful environment that doesn't need 200Kb for each program that displays a dialog box. On the Whitechapel MG-1, as an example of a window manager that did this split right, the average size of a program that uses windows is ~80K. I find this acceptable. Sun just did a bad design (not even speaking of the so-called user interface they give you. Yuck. Not even being able to type without the mouse obscuring your window. Blech), and now they'll have to fix it with concoctions like shared libraries.... -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
rap@dana.UUCP (Rob Peck) (06/08/87)
In article <2194@husc6.UUCP>, hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) writes: > Things would be even better if someone wrote a shared run-time stdio > library and other Sys V function library; then multiple executables, even > totally different executables would have shared text automagically. > > -Mitsu I agree. Using shared libraries can significantly reduce the size of the code that any program needs to have. I have, for example, suggested to the JForth folks that it might be useful to create a version of JForth that was actually a library rather than a program so that calling a version of JForth would be a small program that opened the library effectively passing to the library a new stack frame and local variables for HERE and so on. (BTW, they listened with interest, but are busiest writing the standalone environment compiler and may not be able to tackle this sort of thing for a while.) This would place the entire of a forth kernel accessible on a read-only basis, so to speak, to many programs, with their own individual extensions accessible on a per-application basis. Other programs could do the same. The main limitation, as I see it, is the need to always write reentrant code (as is necessary for libraries for libraries anyway). Library of stdio ... good idea, anyone want to tackle it? Rob Peck ...hplabs!dana!rap
barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) (06/09/87)
In article <7409@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >Sun just did a bad design (not even speaking of the so-called >user interface they give you. Yuck. Not even being able to type without >the mouse obscuring your window. Blech) I don't understand. You can split the focus, having the mouse in one window and keyboard input going to another. You can change this with a mouse command or a function key. see swin(1), etc And how can the cursor obscure your window? -- Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- "The difference between a Buddha and an ordinary man is that one knows the difference and the other does not."
knudsen@ihwpt.UUCP (06/11/87)
In article <178@dana.UUCP>, rap@dana.UUCP (Rob Peck) writes: > Library of stdio ... good idea, anyone want to tackle it? > Rob Peck ...hplabs!dana!rap I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall that OS/K (68000 OS9) does indeed share the whole stinkin' StdIO library, so when you have a half dozen C programs loaded, there's only ONE copy of printf() in memory! No longer need "hello world" take 4K ... mike k PS: there was quite a discussion couple months back on mod.os about ways to implement shared libraries. Somewhat after the fact, but there are several approaches each with good & bad points. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
dibble@rochester.ARPA (Peter C. Dibble) (06/11/87)
In article <1735@ihwpt.ATT.COM>, knudsen@ihwpt.ATT.COM (mike knudsen) writes: > In article <178@dana.UUCP>, rap@dana.UUCP (Rob Peck) writes: > > Library of stdio ... good idea, anyone want to tackle it? > > Rob Peck ...hplabs!dana!rap > > I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall > that OS/K (68000 OS9) does indeed share the whole stinkin' > StdIO library, so when you have a half dozen C programs loaded, OS-9/68K supports "trap handlers." Two of them come with the system: a stdio trap handler and a floating point trap handler. The program does some fussing around to "install" the handler, then it uses a trap to access the routines in the handler. You need a trap per trap handler, so there is a limit on the number of separate libraries a program can use without swapping trap numbers around. The technical manual describes the protocol for the floating point handler. The stdio handler is undocumented, and it looks a bit tricky to call. (Nice thing about the floating point handler: if you have a 68881 you just install the handler that uses it. Programs start using the coprocessor without any changes.) On the 6809 subroutine modules could be used to achieve almost the same effect. Peter Dibble
knudsen@ihwpt.ATT.COM (mike knudsen) (06/13/87)
> > > Library of stdio ... good idea, anyone want to tackle it? > > > Rob Peck ...hplabs!dana!rap > > I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall > > that OS/K (68000 OS9) does indeed share the whole stinkin' > > StdIO library, so when you have a half dozen C programs loaded, > OS-9/68K supports "trap handlers." Two of them come with the system: > a stdio trap handler and a floating point trap handler. The program > does some fussing around to "install" the handler, then it uses > a trap to access the routines in the handler. You need a trap per > trap handler, so there is a limit on the number of separate libraries > a program can use without swapping trap numbers around. > > The technical manual describes the protocol for the floating point > handler. The stdio handler is undocumented, and it looks a bit > tricky to call. > > On the 6809 subroutine modules could be used to achieve almost > the same effect. > Peter Dibble Thanks for the facts, Peter. BTW, I'm cutting this back to just .m6809; I don't think the Big A's want to hear the OS9 details. Seems to me that however you do a shared stdio (C runtime) library, at least some of its code has to map into your process's space during the call. (Yes, 6809 subr modules would do just fine.) This is because of the random way you can throw variables from your program into a printf() or scanf() call. The stdio function has to map into your process space to find all those goodies. Of course this is no worse than a non-shared set of stdio routines. But I'm a little confused by OS/K's trap handlers. Are these in system space? If so, how do they get to the caller's variables? I guess there is no problem in OS/K Level 1, and since a 68K can address 16M, maybe nobody cares that it won't work as easily under Level 2 OS/K. (Microware even advertises a Level 3 OS/K, with swapping or paging to hard disk). Since Atari and Amiga have no MMU/DAT, OS/K Level 1 is all that matters to them for now. (restricted distribution ==> no flames this time!) As for why shared libes haven't been tried on 6809 -- I guess it hasn't been worth the hassle, with relatively few applications written in C. When you relize that all your assembly-coded programs all have their own binary-to-BCD output translation routines (ok, Hex in OS9) you may wish these things were shared. But now with C-coded programs (like Dynastar) available for the Coco 3, it may be worthwhile to rewrite stdio to use subroutine modules. The cstart() fcn linked into your final object code could ensure that the required modules got LOADed just once. Your code would contain just the argument-grabbing opening lines of printf() and its friends. Then the main bulk of printf() and such would be LINKed and UNLINKed on each call. Or (horrors!!) turn things upside down--put the runtime package of C in charge, such that it runs your main() in much the same way that BASIC09 interpreter runs I-code. BTW, BASIC09 does great with 6809 subr modules (Inkey, GFX, GFX2, etc). I may be over my head here, and Microware probably doesn't need any more suggestions this week, but ... oh, well. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
jec@nesac2.UUCP (06/13/87)
Since this has turned into a discussion of Suns, windows, and operating system design, perhaps it should be moved to comp.os.???? instead of being in comp.sys.m6809. -- John Carter AT&T Communications - Atlanta RWC USnail: 3001 Cobb Parkway, Atlanta GA 30339 E-mail: ...ihnp4!cuea2!ltuxa!ll1!nesac2!jec Voice: 404+951-4642 (The above views are my very own. How dare you question them? :-)
dibble@rochester.UUCP (06/13/87)
In article <1738@ihwpt.ATT.COM>, knudsen@ihwpt.ATT.COM (mike knudsen) writes: > Seems to me that however you do a shared stdio (C runtime) library, > at least some of its code has to map into your process's space during > the call. So far OS-9/68K doesn't have a version with memory management. EVERYTHING is mapped into the trap handler's address space. Since the trap handlers only get direct access to the registers, any information that is not in a register (like a line to print), must be seen by dereferencing a pointer (this is a guess, but I can't think of any way around it). If (when) a version of OS-9/68K with full memory management comes out the trap handlers will have to use the sys-call move instructions to follow the pointers. > > Considering subroutine libraries for the 6809. They would be a great idea, and OS-9 was designed for them. The original idea was that vast libraries of packaged solutions would be available in ROM. The idea never caught on perhaps because there weren't enought customers in the OS-9 community to justify the cost of developing the software. The two packages that come with OS-9/68K (stdio and floating point) would certainly make my life with assembly programming for the 6809 easier. I'd be pleased with just the floating point library especially if it included all conversions. Come to think of it, it probably wouldn't be that hard to write one! Maybe we should make a project of it. (If we succeed I think I could get it published.) After a numeric library I'd go for string handling. Problem: If the libraries are mapped into the address spaces that use them, they will use up space there. They could live in a separate address space, and use an rpc-like mechanism, but it would be slower. Peter
knudsen@ihwpt.UUCP (06/15/87)
In article <28454@rochester.ARPA>, dibble@rochester.ARPA (Peter C. Dibble) writes: > So far OS-9/68K doesn't have a version with memory management. EVERYTHING > is mapped into the trap handler's address space. So far I guess you're right, Peter, but Microware sales brochures a couple years ago promised OS/K Level 2 (memory mapping) and even Level 3 (paging/swapping). Maybe these will be out Real Soon Now. As I stated before, the 68000 doesn't need memory mapping nearly as badly as the 6809 does, except for protection. And once you put MMU on a 68K board, everyone wants an OS from the phone company ;-). > > Considering subroutine libraries for the 6809. > They would be a great idea, and OS-9 was designed for them. > The original idea was that vast libraries of packaged solutions > would be available in ROM. The idea never caught on perhaps because Yes, I remember Motorola's "Solutions in Silicon" sales blurbs. These ROM-chip libraries were also touted as one of the justifications for modular and position-independent code, and led to the OS9's boot initilization's amazing ability to tie all the drivers and things together at boot time (the "kernel" has to look for those ROMs, and finds all the RAM modules at the same time). OS9 owes a lot to the ROMs that never were... > Maybe we should make a project of it. (If we succeed I think I could > get it published.) After a numeric library I'd go for string handling. If you (Peter) can't get it published, nobody else can! > Problem: If the libraries are mapped into the address spaces that use > them, they will use up space there. No worse than if they were not shared. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"