On Sun, Jun 29, 2014 at 4:21 PM, Rugxulo <rugx...@gmail.com> wrote: > On Sun, Jun 29, 2014 at 1:19 PM, dmccunney <dennis.mccun...@gmail.com> wrote: > > I think you're mistaking it for ALGOL 60. Because Pascal always had > I/O built-in to the language (and compiler). That part was always > there, even before ISO got involved.
Not in Wirth's original design for the language, it wasn't. As stated, it was intended to be a teaching tool, and there was no assumption of Wirth's part that it would actually be implemented on a machine. Pascal also suffered from lack of standards. There were lots of Pascal implementations, all different in various ways. You could not expect to write Pascal code that would build an run, for example, on a PC under Turbo Pascal, and a DEC VAX under DEC Pascal. C did get standardization efforts, with the intent that you should be able to write C that would build and run on any machine with a standards compliant C compiler. This did not happen automatically, and you had to understand what sorts of things *were* portable. Netscape's documents on portability for folks working on Mozilla code are amusing because of this. Mozilla uses C++ instead of ANSI C, but the same issues apply. A lot of what is in the Netscape docs reduces to "Just because you can do it in MS C++ compiled by Visual C++, don't assume it will work elsewhere. It probably won't." And yes, Algol 60 did not define I/O, resulting in wide variance of implementations. > Some compilers are faster (on certain OSes) if you don't shell out to > run the assembler for every file. But it makes cross-compilation much > harder. Cfront didn't shell out for each file. Cc compiled all source files to assembler, the passed the list to as for assembly, and that list was passed to ld to build the executable, all under the control of make. > But the problem we're seeing here is dead code that is never called > but still linked in. It's not just code that is rarely used, actually > stuff that is completely useless. But most compilers can't tell the > difference, smartlinkers aren't that common, and libraries aren't > often hand-optimized. Modern compilers do indeed try to optimize out dead code. They detect that something is never actually called, and simply don't compile it. There used to be a Texas outfit called Convex Computers back in the 80's. Convex made "baby super computers". You bought one if you couldn't afford $5 million for a Cray, but *could* afford $250K for a Convex box. Convex realized that the vast majority of programs were I/O bound, not compute bound. The CPU spent most of its time in a wait state while I/O took place. So Convex built boxes with off-the-shelf components but with a *lot* (for the time) of RAM. The idea was to read the entire dataset you were manipulating into RAM and then run the code on it. Convex would do demos where their machine would scream through the calculations. The customer would say "That's not *fair!* I can't *do* that on my VAX!" and the Convex reps would grin and say "Right! That's why you're talking to us." Convex also put a lot of work into optimizing compilers, so a customer would say "What just happened?" The Convex rep would say "Oh, the compiler realized that block of code was never called, and didn't compile it.", and the customer would say "I'll be damned! I've been maintaining that code for 10 years and I never noticed that!" We are at the point now where you *don't* try to hand optimize your code. You let the compiler do it. The sort of things you might do to hand optimize may fool an optimizing compiler, and result in bigger and slower object code than you would get if you let the compiler handle it. You can pass hints to the compiler on the command line about the kind of optimization you want, like whether you are trying to optimize for speed or size, but in general, the compiler can do it better than you can. And libraries do get optimized. One effort I follow is toybox. Toybox is intended to be a replacement for Busybox, and it the work of the foremer Busybox maintainer. One of Toybox's goals is to use musl instead of the standard C libraries on Linux, because musl's stuff is a lot smaller, and often quicker. Compiler technology has advanced far beyond the sort of tricks you had to play in resource constrained environments like MS-DOS on 8088 based machines. ______ Dennis ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
