ron@iconsys.UUCP (Ron Holt) (06/28/88)
Recently, there has been fear expressed that evil AT&T and Sun will
some how optimize future versions of Unix for SPARC. Considering the
portability of Unix being one of its best known traits, wouldn't this
be rather difficult to do? I wouldn't consider BSD optimized for the
VAX nor SVR3 optimized for the 3B2 even though these machines were
used as the porting bases for their respective Unix variants. Of course,
there are very machine specific sections of the Unix kernel, the VM code
being a good example, but other than that, how could Unix be optimized
for SPARC?
--
Ron Holt UUCP: {uunet,caeco}!iconsys!ron
Software Development Manager ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu
Icon International, Inc. BITNET: icon%byuadam.bitnet
Orem, Utah 84058 PHONE: (801) 225-6888barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (06/29/88)
In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: |Of course, |there are very machine specific sections of the Unix kernel, the VM code |being a good example, but other than that, how could Unix be optimized |for SPARC? I agree with your sentiment. Optimizing it for a RISC machine, along with the other ABI's, should increase the portability of the kernal. But that is an old topic. The new one is that OSF plans to remove all of the AT&T code eventually. Does anyone have a guestimate on the amount of effort this would take? And how do you prove you weren't influenced by the AT&T code? Methinks the lawyers will be busy for a while. And the programmers. Maybe after the project is done, you can license OSF UN*X for merely twice the price of AT&T UNIX. :-) -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
gallen@apollo.uucp (Gary Allen) (06/30/88)
In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: > >Recently, there has been fear expressed that evil AT&T and Sun will >some how optimize future versions of Unix for SPARC. Considering the >portability of Unix being one of its best known traits, wouldn't this >be rather difficult to do? I wouldn't consider BSD optimized for the >VAX nor SVR3 optimized for the 3B2 even though these machines were >used as the porting bases for their respective Unix variants. Of course, >there are very machine specific sections of the Unix kernel, the VM code >being a good example, but other than that, how could Unix be optimized >for SPARC? >-- >Ron Holt UUCP: {uunet,caeco}!iconsys!ron No one has called Sun or AT&T evil (although some people seem to believe them altruistic). Every person, organization, and company is full of built-in predjudices about the way things are, the way things should be, what's "normal" what's not, etc. Unfortunately, these biases affect the way we all do things. People by their nature do what's in their interests, hardly realizing that what they percieve as the normal correct way to do things is only so in their own context. Do you believe that UNIX ala SUN/AT&T would just HAPPEN to work out well for Apollo's PRISM risc machine and poor for their own SPARC? Hardly! That's not evil on their part nor is there some conspiracy to do anybody in. A tiny tiny tiny tiny example: years ago, I worked with a machine whose native mode of handling chars was unsigned. Now, K&R's C manual specifically stated that the sign of the 'char' type was machine dependent and beyond the scope of the C language definition (yeah, I know the diff between C and UNIX). So, C chars on that machine were implemented unsigned; seems pretty reasonable huh? Well, you wouldn't believe all of the trouble that this caused. There was much UNIXage that simply wouldn't work right, let alone dozens of customer applications that had to be #ifdef'ed to death, if we could even get their business (porting was a BIG deal in those days). The situation was so bad that we had to take a performance hit (on a machine whose main virtue was brute horsepower) and simulate signed characters. Where was the evil, the conspiracy, incompetence, or brilliance. Nowhere!! That's why the Celtics aren't allowed to provide the referees when they play the lakers, and why my ex-wives (thank god) weren't allowed to pass divorce decrees. NOBODY IS IMPARTIAL!! I don't represent anybody, I'm totally irresponsible. Gary Allen Apollo Computer Chelmsford, MA {decvax,yale,umix}!apollo!gallen "Oh Yeah, our CEO can beat up your CEO!"
ron@iconsys.UUCP (Ron Holt) (06/30/88)
In article <4722@vdsvax.steinmetz.ge.com> barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: >In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: >|Of course, >|there are very machine specific sections of the Unix kernel, the VM code >|being a good example, but other than that, how could Unix be optimized >|for SPARC? > >I agree with your sentiment. Optimizing it for a RISC machine, >along with the other ABI's, should increase the portability of the kernal. > >But that is an old topic. The new one is that OSF plans to >remove all of the AT&T code eventually. Pardon me for asking a question for which you already know the answer. At least you could have answered my question before changing the subject. I have not read every article that has ever been posted to this group. I would still like an answer to the original question. Why is there all this fear that AT&T/Sun will steer the evolution of Unix towards a particular chip considering Unix's characteristic of portability. This fear seems unfounded. Email me if this has already been discussed. >Does anyone have a guestimate on the amount of effort this would take? >And how do you prove you weren't influenced by the AT&T code? These would be a good questions for Richard Stallman since he is also trying to produce a version of Unix free of AT&T code. He states in the GNU documentation: "I must avoid reading Unix source code." The founding OSF members certainly have read AT&T source code. -- Ron Holt UUCP: {uunet,caeco}!iconsys!ron Software Development Manager ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu Icon International, Inc. BITNET: icon%byuadam.bitnet Orem, Utah 84058 PHONE: (801) 225-6888
ron@iconsys.UUCP (Ron Holt) (06/30/88)
In article <3cf43568.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: > >No one has called Sun or AT&T evil (although some people seem to believe >them altruistic). I disagree. That seems to be exactly the implication of many articles I have read on the net and in the press. The first issue of Unix Today! exhorts AT&T not to "go off with Sun and optimize Unix for SPARC." (p. 18). >NOBODY IS IMPARTIAL!! I agree. But the OSF wasn't founded because of potential inadvertent oversights on AT&T's part that might give them an advantage in the Unix world. I don't believe them "evil" either. That's my point. I'm trying to refute the simple-minded idea that AT&T can intentionally direct the evolution of Unix to the advantage of SPARC based machines. Enough said. -- Ron Holt UUCP: {uunet,caeco}!iconsys!ron Software Development Manager ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu Icon International, Inc. BITNET: icon%byuadam.bitnet Orem, Utah 84058 PHONE: (801) 225-6888
gallen@apollo.uucp (Gary Allen) (06/30/88)
In article <4722@vdsvax.steinmetz.ge.com> barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: >In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: >|Of course, >|there are very machine specific sections of the Unix kernel, the VM code >|being a good example, but other than that, how could Unix be optimized >|for SPARC? > >I agree with your sentiment. Optimizing it for a RISC machine, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >along with the other ABI's, should increase the portability of the kernal. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, I don't understand this at all! >But that is an old topic. The new one is that OSF plans to >remove all of the AT&T code eventually. Not according to any statement made by anyone at OSF. This was/has been asked of OSF related people here at Apollo on many occasions and the answer is that while they would love to have a non-AT&T UNIX, the legal problems were viewed as practically insurmountable. [.......] >Methinks the lawyers will be busy for a while. And the programmers. Nyet, my ex-wives have them all (the programmers too!). >Maybe after the project is done, you can license OSF UN*X for merely >twice the price of AT&T UNIX. :-) Actually, most customers license their OS from their hardware vendor who, in turn, license it from AT&T or even a software house who licenses it from AT&T; therefore, most licenses are transitive. What does it matter to you (if you're a customer instead of a vendor) where the vendor got it. I think customers are more concerned about what software they'll get at what quality at what bottom-line cost. Gary Allen Apollo Computer Chelmsford, MA {decvax,yale,umix}!apollo!gallen "No man is an island. No man is a potato salad either."
mash@mips.COM (John Mashey) (07/01/88)
In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: > >Recently, there has been fear expressed that evil AT&T and Sun will >some how optimize future versions of Unix for SPARC. Considering the >portability of Unix being one of its best known traits, wouldn't this >be rather difficult to do? I wouldn't consider BSD optimized for the >VAX nor SVR3 optimized for the 3B2 even though these machines were >used as the porting bases for their respective Unix variants. Of course, >there are very machine specific sections of the Unix kernel, the VM code >being a good example, but other than that, how could Unix be optimized >for SPARC? From outside, there are two issues: a) The marketing one: some of the Sun sales/marketing materials we've seen have explicitly said "standard UNIX would be optimized for SPARC", including Bernie LaCroute's page in the SunTechnology magaizine of January or February. At least some Sun engineers expressed mystification to me as to what this was about, given that they needed to support SunOS on at least 2 other architectures :-) b) There are certainly restructurings of the kernel that might be more conducive to SPARC (of which the SunOS crew is certainly aware). I can think of ways to restructure the kernel to help performance on SPARC. Depending on how they were done, they could either be neutral with regard to other OSs, or slightly negative; one would assume that people will not make changes that damage 68K or 386 performance. There are 2 instantly obvious changes: a) [SPARC-specific]: macro-ize or otherwise restructure the kernel to lessen the dynamic depth of function calls. When I've watched kernels go, they quite often end up 10-12 deep inside the kernel, plus 3-5 deep (fairly quickly) in the user program. This of course is the reverese of the directionthat the kernel has been going, i.e., with more layers and indirects for cleaner structuring. b) [not SPARC-specific, but relevant]: handle the u_area differently. The kernel's habit of mapping the u_area into the same kernel-virtual address causes painful problems in context-switching for virtual address+virtual tag machines of some kinds, i.e. you need to flush cache pages on each context switch. This is NOT specific to SPARC [the 3/2xx has the same issue], but is relevant, since: a) THe faster the machine gets, the larger hit you take from cache-flushing activities and resulting misses. b) Most other RISC machine don't use the kind of virtual-virtual caches that current SPARC implementations do, so they don't have the problem; hence any overhead introduced to solve this problem may get in the road. (I don't think this is a big issue, as UNIX needs to get restructured carefully to handle different flavors of cache and MMU design better anyway.) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/02/88)
There are two reasons why UNIX won't get to be a SPARC o/s. You can
believe at least one of them.
a) Sun and ATT are nice guys and wouldn't do a thing like that.
b) Sun and ATT support, sell, or use 68k, 386, SPARC, 3Bxx, VAX. I
realize that ATT will probably phase out the remaining VAXen, but I
would expect the rest of the crowd to stay.
A freind who works for ATT tells me that what runs in the switches as
UNIX, but I don't know if that's true, and if the switches are some form
of 3B.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merwhite@nusdhub.UUCP (Robert C. White Jr.) (07/02/88)
in article <2482@winchester.mips.COM>, mash@mips.COM (John Mashey) says: > > In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: >> >>Recently, there has been fear expressed that evil AT&T and Sun will >>some how optimize future versions of Unix for SPARC. > > From outside, there are two issues: > a) The marketing one: some of the Sun sales/marketing materials we've > seen have explicitly said "standard UNIX would be optimized for SPARC", As I understood iti, durring the University UNIX Users Group ("U3G") meetings a couple months back, the following was going to happen: SVR3.2, the Unix/Xenix merge, would be released and then an ABI would be set for the 386 family. SVR4, the Unix/Xenix/Sun merge, would be released with an ABI set for SPARC and the 386 family. SVR5, a re-write of SVR4 entirely in C++ SVR4 may be the C++ version, I don't remember for shure, but Cassoni explained it thus: AT&T has a vested intrest in keeping the "basis" for all UNIX System products as universally useable as possible. The aledged universality of UNIX being the only thing that makes it different from "all those other operating systems" (refering to VMS, DISOS, and a few others by name.) Aparently the truley optomiseable <real word?< portions would be seperated from the main text in a much more tangable way, useing modules and assemblies. AT&T's current marketing stratagey (provided with many glossy color brochures) involves maintaining a very-available source code base, "as many exclusive ABI's as possible" <my paraphrase.< by which it was menat that where processor arcitecture differed greatly, and agreements could be reached I assume, an ABI would bes set; the guiding rule being, _NO OVERLAP_ in arcitectures/ABIs. Centroid to this was that sources (including the available assemblies) would be "at least as easy to obtain as is currently the practice" <as close as I can come to an exact quote.< Whe asked "why?" Cassoni explained that the real purpose of the merging of products was twofold: 1) people were demanding (common) BSD features like jobcontrol, better signal handeling, and (uncommon) aditional features like "real time" functioning (whatever you take that to mean.) 2) The secucess of the small computer industry was largely due to the availability of "off the shelf" "shrink wrapped" products. Number two seems to be the big issue. AT&T wants to sell product, that should be obvious. If they can manufacture a compleetly uniform product that _everybody_ wants and uses regularly they win twice. One, they can open a competitive market of applications software which needs only to be re-compiled every time someone invents/produces a new computer. And Two, if they can make _everybody_ want their product ( c.f. UNIX ) then they can sell it to everybody. By opening up the standard compleetly, listening to every word spoken by the standards commities, and setting a fair/just/honorable/uniform ABI for every arcitecture they possibly can, they encourage everybody to buy thir product. Because of their licence agreements issued to date (esp version 2 licences) they can't come out and _make_ everybody buy some new and hardware spesific monster, their only choice it to try and make _everybody_ want the new and improved versions. By being nice to everybody, and catering to every possible public whim, AT&T could win very big. This is all common sense, but nobody has tried this aproach before, so everyone is suspicous. Just think, if you held a always and forever patent on the internal combustion engine (from day one), and you put a licencing and usage fee of $1 each, payable after construction with no further usage fees or anything, you would be rich and nobody would have really minded at all (if it had started out that way.) This is what AT&T seems to be trying to do. Disclaimer: These are opinions based on presentations made by AT&T, nothing more and nothing less. Rob White National University.
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (07/02/88)
In article <3cf8d4d5.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: |>But that is an old topic. The new one is that OSF plans to |>remove all of the AT&T code eventually. | |Not according to any statement made by anyone at OSF. I read this in one of the trade journals last week. (Can't find the issue). But someone from IBM announced that their eventual plans were to remove all of the AT&T code. I apologize for not having the reference. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
len@mips.COM (Len Lattanzi) (07/03/88)
In article <4741@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: :In article <3cf8d4d5.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: :|>But that is an old topic. The new one is that OSF plans to :|>remove all of the AT&T code eventually. :| :|Not according to any statement made by anyone at OSF. : :I read this in one of the trade journals last week. (Can't find the issue). :But someone from IBM announced that their eventual plans were to :remove all of the AT&T code. : :I apologize for not having the reference. :-- : Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> : uunet!steinmetz!barnett See Computer Systems News 6/27/88 "OSF Plans Sunset for AT&T Code" Ira Goldstein, temporary director of research for OSF and formerly manager of R&D for technical systems at HP, made the announcement. -- Len Lattanzi (len@mips.com) <{ames,prls,pyramid,decwrl}!mips!len> Synthesis Software Solutions, Inc. 292 Commercial Street, Sunnyvale, CA 94086 408-991-0367
gallen@apollo.uucp (Gary Allen) (07/06/88)
In article <2535@gumby.mips.COM> len@gumby.UUCP (Len Lattanzi) writes: >In article <4741@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >:In article <3cf8d4d5.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: >:|>But that is an old topic. The new one is that OSF plans to >:|>remove all of the AT&T code eventually. >:| >:|Not according to any statement made by anyone at OSF. >: >:I read this in one of the trade journals last week. (Can't find the issue). >:But someone from IBM announced that their eventual plans were to >:remove all of the AT&T code. >: >:I apologize for not having the reference. >:-- >: Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> >: uunet!steinmetz!barnett > >See Computer Systems News 6/27/88 "OSF Plans Sunset for AT&T Code" > >Ira Goldstein, temporary director of research for OSF and formerly >manager of R&D for technical systems at HP, made the announcement. >-- > Len Lattanzi (len@mips.com) <{ames,prls,pyramid,decwrl}!mips!len> > Synthesis Software Solutions, Inc. > 292 Commercial Street, Sunnyvale, CA 94086 408-991-0367 Touche. I couldn't find that particular mag in the library, but I'll accept what you say. However, I'll restate what was in my follow-up. Sources close to OSF (you know who you are) were asked repeatedly about this subject. The answer was always that the legal problems were practically insurmountable. Thus, it would be practically impossible to avoid royalties to AT&T. Given that, its hard to see what benefit there would be in replacing code with other code that does the same thing. Improving, polishing, optimizing, and just plain hacking may well be in the picture but replacing AT&T code just because it is that seems a little silly if they have to pay for it anyway. Gary Allen Aplool Computer Chelmsford, MA {decvax,yale,umix}!apollo!gallen Oh yeah, you know that stuff about how this doesn't represent the opinion of anybody that really counts. I wasn't a math major anyway.
bzs@bu-cs.BU.EDU (Barry Shein) (07/06/88)
It seems to me that the vendors in OSF could freeze at their current level of AT&T license (eg. SysVR3.1) and proceed to develop whatever they wanted from there using as much or as little of the original source as pleased them. My guess is that the licensing and royalties would remain the same indefinitely, which I infer was acceptable at some point. The only possible loser in that game would be new organizations who can no longer purchase older AT&T source licenses and find current ones somehow unpalatable (or inappropriate.) This of course does not give them (OSF) any freedom with the sources in terms of distribution (at least source still containing AT&T code) but I'm not convinced that this is in conflict with their goals. You want their (OSF's) full source dist? You'll have to produce a bona-fide AT&T source license (and, perhaps, an additional OSF source license.) Not a whole lot unlike the current BSD/CSRG situation, first produce a (possibly mildly ancient, 32v will do in this case) AT&T license, then obtain or produce a BSD license, fair enough. The problems people seem to be having here is deciding what the goals might be, rather than the means to attain them (tho many have jumped to this latter topic.) Too many assume that OSF's (immediate) goals are to produce yet another Unix from the ground up, something I'm not convinced of particularly. I might be convinced they intend to produce another Unix beyond the current version, distinct from SysVR4 (again, similar to BSD's traditional position, tracing down from V7), and present it as a multi-vendor standard among OSF members and otherwise try to generate interest, particularly in getting the US Govt to approve it as acceptable in RFP bids etc where "Unix" is required, I would imagine the vendors involved have a good chance of accomplishing that. Voila', a frozen external situation (with AT&T) and a Unix product just as our tax bucks require. Nothing particularly evil or vile here, just an observation that one can (as always) purchase a version of AT&T's code and proceed wherever they like with it as a proprietary product with the major risk being (other than obeying the original licensing restrictions) that of becoming either de facto or de jure non-standard. An organization like OSF could fight that image, hard to be damnably non-standard when N different major vendors are shipping the stuff, a different standard perhaps. Of course, plans of mice and men and all that... -Barry Shein, Boston University
Richard@boingo.dec.com (Richard Wood) (07/06/88)
> It seems to me that the vendors in OSF could freeze at their current > level of AT&T license (eg. SysVR3.1) and proceed to develop whatever > they wanted from there using as much or as little of the original > source as pleased them. My guess is that the licensing and royalties > would remain the same indefinitely, which I infer was acceptable at > some point. The only possible loser in that game would be new > organizations who can no longer purchase older AT&T source licenses > and find current ones somehow unpalatable (or inappropriate.) Barry - You've got it almost completely right. The problem with using a base level of AT&T SysVr3 is that the licensing restrictions are not "in perpetuity". In other words, AT&T reserves the right to renegotiate the license, or even revoke it. I believe they may do this at any time, although it may only be at renewal periods. By using a base level of SysVr2, the irrevokable license that IBM managed to negotiate will always apply. AT&T can't renege, assuming that they would want to. This obviously makes it a much more palatable base from which to develope. OSF can then do whatever they please with "OSFix" - neither AT&T nor IBM have any claims over it. One of the implicit terms that the sponsors agreed to was that once a "technology" has been "donated", the T&Cs cannot be revoked. So IBM has no more authority than any other member over what OSF does to (what used to be) AIX. I see your point about the "possible loser". But then, this problem currently exists with BSD distributions. How is it handled there? Can companies still get 32V or SysVr2 source licenses? The only real losing point would be if the price for a new source license from AT&T went sky high or became unavailable. OSF has committed to keeping their relicensing terms agreeable (remember: they are non-profit); that leaves the ball in AT&T's court. It should be pointed out that AT&T probably couldn't apply different source costs to OSFix customers than their own; so they can't hurt OSF customers without cutting their own throat. NOTE that I do not believe that AT&T would do any of these things; companies do not do nasty things gratuitously. However, it looks like OSF and those "millions of lawyers" have arranged things so that AT&T's best and/or legal interests never conflict with OSF's. Which is exactly what the lawyers were hired to do, I suppose. -- ---------------------------------------------------------------------------- It should go without saying that I'm not speaking as an official representative of DEC ------------------------------------------------------------------------------- Richard Wood ! Software Services, San Francisco ! Digital Equipment Corporation
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/06/88)
I am a believer in letting the market decide. Therefore I urge ATT to
reinstate the practice of releasing UNIX for VAX. I would also like to
see Amdahl make the SRV4 available in a form which would run on the
large IBM iron (or ATT if Amdahl doesn't). Maybe ATT could contract
someone to do the port to Apollo, too. OSF seems to say that they want
open competition, so ATT should assist them by offering SRV4 for all of
the commercially significant machines made by OSF members.
Of course if OSF was willing to recognize the existence of competing
machines they could offer IAX for the Suns and 3B series, but I can't
imagine that happening.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mebzs@bu-cs.BU.EDU (Barry Shein) (07/06/88)
Fascinating data point! IBM negotiated an "in perpetuity" SysVR2 license with ATT. OSF will use IBM's AIX as a base for their Unix. Put those together and everything becomes *much* more clear, thanks! As to newcomers needing licenses I would guess that they can choose between buying whatever is current from AT&T and then applying for an OSF license or simply become some sort of OSF redistributor, perhaps that's the loophole, sublicensing under OSF's license, so anyone joining up with OSF can basically negotiate T&C's with OSF and AT&T is a minor factor. I know that AT&T sold (pricey) licenses which allowed various sublicensing, tho I thought that was basically binary-only sublicensing, then again, make your changes within the auspices of OSF itself and have them sublicense the changes back to you, as long as ownership of the changes remains within the foundation that should be legitimate and it serves the "sharing" aspect to some extent (somewhere everyone has to get his/her head into an appropriate noose, that's typical in these joint technology ventures, having to sublicense your own changes from the foundation sounds about right.) It also explains a little more clearly why OSF needs the development facilities they seem to be building. If all that's close to correct things are starting to make a lot more sense. -Barry Shein, Boston University
aledm@cvaxa.sussex.ac.uk (Aled Morris) (07/11/88)
In article <253@iconsys.UUCP>, ron@iconsys.UUCP (Ron Holt) writes: > Recently, there has been fear expressed that evil AT&T and Sun will > some how optimize future versions of Unix for SPARC. Considering the > portability of Unix being one of its best known traits, wouldn't this > be rather difficult to do? I wouldn't consider BSD optimized for the > VAX nor SVR3 optimized for the 3B2 even though these machines were > used as the porting bases for their respective Unix variants. Of course, > there are very machine specific sections of the Unix kernel, the VM code > being a good example, but other than that, how could Unix be optimized > for SPARC? I'm not worried about an evil plot, but have you thought about the hardware (implementation) dependencies that get wired into systems without anyone noticing? In a way, BSD *is* optimised for a Vax, since there is lots of code that has hardwired in a dependency on the dereference of the address zero returning zero, that pointers and ints are interchangaeable, etc. etc. [NO FLAMES PLEASE...] Likewise, when writing for the SPARC I would keep my procedure argument lists to <= 6 args, so they'll all fit into the register window, etc. etc. [I CAN HEAR YOU ALL GROANING ALREADY] It takes a mammoth effort to write code which is truly portable, and I don't mean just the machine-specific bits. If AT&T write code for the SPARC, expect to see SPARC-isms wired in. THIS IS NOT GOOD. Aled Morris systems programmer mail: aledm@cvaxa.sussex.ac.uk | School of Cognitive Science uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex talk: +44-(0)273-606755 x4284 | Falmer, Brighton, England "I'm living in the future/I feel wonderful/I'm tipping over backwards... I'm so ambitious/I'm looking back/I'm running a race and you're the book I read"
guy@gorodish.Sun.COM (Guy Harris) (07/19/88)
In a way, BSD *is* optimised for a Vax, since there is lots of code that has hardwired in a dependency on the dereference of the address zero returning zero, that pointers and ints are interchangaeable, etc. etc. [NO FLAMES PLEASE...] Actually, the "dereference of address zero returning zero" stuff was cleaned up quite a bit when the 4.2 stuff was ported to Suns; I'd rate BSD as better than S5 in this case, at present. Of course, AT&T could fix this by making the "-z" flag to the linker be the default; *that* would teach people not to **** with null pointers. > Likewise, when writing for the SPARC I would keep my procedure argument > lists to <= 6 args, so they'll all fit into the register window, etc. etc. > [I CAN HEAR YOU ALL GROANING ALREADY] Of course, keeping procedure argument lists shorter than 6 arguments has plenty of *other* advantages, like keeping the procedure from becoming too baroque. I don't think I've often needed long procedure argument lists, other than in calls to "printf"; I don't "write for the SPARC", though, so when long argument lists were called for I just used them, despite the fact that my machine happens to be SPARC-based. > It takes a mammoth effort to write code which is truly portable, > and I don't mean just the machine-specific bits. If AT&T write code > for the SPARC, expect to see SPARC-isms wired in. THIS IS NOT GOOD. AT&T's machines use the WE32K, the SPARC, and the '386; Sun's machines use the 68K, the SPARC, and the '386. With any luck, this will result in fewer *-isms, unless it results in more of them (6 arguments per procedure for the SPARC *and* only N register variables for the '386 or whichever processor has fewer registers left over). At least most of those machines have signed characters, so there won't be tons of "8-bit clean" code that assumes that characters are unsigned, as there was in S5R3.1. Since one of them doesn't, one would hoep that there would also be no code that depends on characters being *signed*.
allbery@ncoast.UUCP (Brandon S. Allbery) (07/28/88)
As quoted from <495@cvaxa.sussex.ac.uk> by aledm@cvaxa.sussex.ac.uk (Aled Morris): +--------------- | It takes a mammoth effort to write code which is truly portable, | and I don't mean just the machine-specific bits. If AT&T write code | for the SPARC, expect to see SPARC-isms wired in. THIS IS NOT GOOD. +--------------- Wired-in Vax-isms are better? (This from a proponent of 386 and 680x0 systems, both of which tend to dump core on *(NULL), the world's favorite Vax-ism.) AT&T will be producing SVR4 for: * SPARC * 68020 (Sun 3's aren't going to disappear in a puff of smoke) * 80386 (Sun 386i; AT&T 6386E) * WE32[01]00 (3B2/3B5/3B20 isn't entirely dead yet) I doubt that they can wire in SPARCisms without slitting their own throats! ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc