Date: Mon, 1 Jun 1998 19:04:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rkw@dataplex.net (Richard Wackerbarth) Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object Message-ID: <199806011904.MAA04619@usr01.primenet.com> In-Reply-To: <l03130301b1977e68fd4e@[208.2.87.10]> from "Richard Wackerbarth" at May 31, 98 09:57:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I was meaning a library in the sense of emulating otherwise discarded > constructs. This is the point of having a well defined API. THe one case you can point to in FreeBSD is the dropping of the ISO and other family functions from libc. Having an emulation library would not help you here, since these are kernel hooks. For standard libraries, the libraries stay around. If they are in XANDF, it won't even matter what architecture we eventually run. > >>By the time we get to FreeBSD 235.x, do you really expect to be > >> able to support today's hack dejuor which relies on the present major/minor > >> device numbers? I think not. > > > >Quite right. Software which depends on these constructs will fail to > >operate. > > You have conceded my point. You conceded first by stating that what you were talking about was a hack. > >Well, I am (I hope) well known as an advocate of "revolution instead of > >evolution"; technology moves too damn slow for me as it is > > If you are successful, FreeBSD will not reach 235.x. It will have gotten > another name long before. I doubt that. BSD can absob technology and remain BSD. The 2.x systems didn't support NFS, for example; is BSD any less BSD now that it does support NFS, yet has dropped support for the old "berknet" serial networking? > >I agree that at some point you are going to lose backward compatability; > >I think, however, that XANDF will push this off, since most of the > >historical compatability issues can be resolved by regenerating the > >assembly code, and relinking, which is implied. > > I don't disagree. However, "push ... off" is far different from your > initial statement. My initial statement was intended to underscore the irrelevence of not moving an ABI forward when it becomes obvious that it should be done. ELF is one very good example. IMO, -current users should all be running ELF systems now; -current is not -release, and the sooner -current moves to ELF, the faster things can be tested. The fact that you have to drop slash-screen support, etc. to get a dual boot is irrelevent. We should take the hack, with the expectation of getting rid of the a.out boot code to resolve the size issue at some future date. Moving to the TenDRA compiler has a lot of advantages: 1) It forces FreeBSD to actually seperate machine dependent and machine independent code. This is a good thing. I think it would be an error to support inline assembly in the TenDRA compiler. 2) It's already machine independent. 3) It supports both Linux and UnixWare, among other UNIX-like OSs. If it becomes widely adopted, then it will be possible to buy a single shrink-wrapped version of a product to run on any UNIX platform. 4) It has a BSD/CMU style license. 5) It is a revolutionary rather than evolutionary product; that is, it was designed to be the way it is, rather than starting as something else and growing warts to become what it is today. Multiple language back-ending, seperation of code generation, etc., are all warts, as far as GCC derived sources are concerned. It also has a couple of disadvantages: 1) We, as programmers, have to actually think about architectural dependence of our code. 2) It has a bit of a problem with not supporting the #pragma pack(#) construct, which is needed to map hardware registers (it uses a packing of 4, but bitfields are correctly handled. The first disadvantage is an advantage, to my mind. 8-). The second is somewhat of an advantage, in that we should be dealing with bitfields anyway, instead of sized types (C doesen't support sized types, one of its major failinures, IMO). > >I *really* look forward to the day when I can buy an XANDF Motif > >library, and use it on all my hardware, regardless of the CPU type. > >8-0. > > Aren't we really just emulating an "XANDF" machine with an XANDF->whatever > micro-code expanded inline? Where is my XANDF native machine? No. There is a fundamental difference here. XANDF is not JAVA; it's not a bytecode format, it's a distribution formant. The code still needs architecture specific peephole optimzations, etc.. I doubt it would be possible to build an XANDFVM. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806011904.MAA04619>