Date: Sun, 31 May 1998 22:13:11 +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: <199805312213.PAA16988@usr06.primenet.com> In-Reply-To: <l0313030fb196e885c687@[208.2.87.10]> from "Richard Wackerbarth" at May 31, 98 11:30:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> As much as we might like to think otherwise, assumptions about the structure > >> of the underlying OS and "hardcoded" into the source of the program. :-( > > > >The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not > >the reverse. In other words, "compile once, run anywhere". > > > >The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a > >problem for the XANDF processor during the install. > > And for it to be possible, there must be a "compatability library" of some > kind. This is false. If you install from an XANDF "binary", you regenerate the assmebly code, and you relink. When you relink, you will relink against whatever the current libraries are. If you are worrying about binary compatability, well, we already shoulder this burden for previous releases of FreeBSD, and previous releases of Linux, for that matter. > FreeBSD in its totality. What are you going to do when a concept entirely > disappears? As an example, consider the impact of the eventual integration > of devfs. 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. This is as expected as software depending on WIN32 constructs failing to operate on FreeBSD now. > As systems evolve, you are eventually forced to abandon the albatroses > of legacy compatability. But they make such lovely necklaces... ;-). > An even harder problem is related to timing assumptions that are > hardcoded into programs. Many programs "work" only because they > assume things about the hardware and/or compilers. Like support for generating 386 assembly inline in nominally machine independent code? I am aware of the issues. The timing issues are less important, cv: > Remember programs that "poked" an I/O register and controlled the > timing with delay loops? FreeBSD still has some of this; and yes, they fail on some systems where the I/O space is cached. Linux has "fixed" these by doing a write as well as a read, which results in a cache flush, and yes, FreeBSD still has some bugs in this area, especially inre. keyboards and LEDs. > They would never work today if a "decent" compiler were to get hold > of them and optimize away the code that simply created delays. Not permissible, if the memory and/or I/O space addresses are marked volatile, as they should be. > Where they were written, the languages never had the concept of > optimization. The languages *did* have this concept. The problem is the ANSI C committees decision to allow certain types of optimization unless it was specifically disallowed. Yes, this broke a lot of programs, until the 'volatile fairy' sprinkled 'volatile dust' throughout the code that depended on compilers that believed in "above all else, do no harm". I blame compiler writers, since compilers should know about the hardware they are pretending to target. But that is another discussion... ;-). > As a result, the programmers never put the necessary hooks into > the program to guide the compiler about which factors are important. The problem is that the language changed, and there was an (invalid) assumption of unimportance "unless otherwise stated". Negative logic tends to back you into this type of incompatability corner. Part of the other discussion (see above)... > All that I am saying is that I do not believe that it is possible to > both maintain infinity compatability and allow for future innovation. > At some point, the two concepts reach a point of unresolvable conflict. > After that point, one of then will no longer apply. 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, since I can see the next vista, tantalizingly just out of reach, and it annoys the hell out of me. 8-). It's not just computer science, either, it's everywhere. 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 *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. 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?199805312213.PAA16988>