I routinely write stuff for devices that small, and after a while you get used to it. These days I'm on a platform where 64 kilobytes is shared between code and data of up to 8 threads of execution. At least I have 500 MIPS to play with.
We passed the point where "normal" people care about execution speed a while ago. Does it matter whether your spreadsheet needs 2 milliseconds longer to calculate the results? I mean, instead of 0.2 you now need 0.202 seconds, do you notice? Do you care? Today, you can waste processing time on animating cursors and create colorful file copy animations. Why bother with optimization?
I care. I'm pissed that current, so-fast-it's-silly hardware, coupled with bloated software, provides me with a system that is less responsive than stuff we had in the 80s. Yes, I do care. Every time I see a spinning beach ball or the application is not reacting to input, I waste time. 0.2 seconds is a LONG time in terms of UI latency. It's well documented I think that this sort of a delay starts to kill productivity, never mind on-the-job satisfaction.
Moving data between RAM and CPU takes a finite and easy-to-measure amount of energy per each byte. Same goes for transfers between memory and peripherals.
Not in Pascal, not even in assembly if you were using CP/M or DOS!!! Opening a file and reading a block would probably fit in 32 bytes of machine code for both CP/M and DOS, file name excluded.
MetaWindows -- hey, I remember that. Was quite nice for what it did.
DOS did a minimal amount of stuff for the keyboard and screen IO -- those were pretty much thin wrappers around BIOS calls, merely allowing you to throw in a different driver that could do, say, terminal emulation (ansi.sys, anyone?).
Its file system implementation, at least in the early days (up to dos 3.3, as that's how far my reverse engineering went), was pretty much toy-like and sucked dick, so to speak.
DOS and BIOS were designed for single-threaded programming, even though there was plenty of knowledge back then from UNIX as to how to design a compact system that would allow if not full-blown multiprocessing, then at least asynchronous I/O. It didn't require any rocket science coding either, I routinely do cooperative, priority-driven preemptive multitasking on hardware with 80s-era memory sizes (48kb for code, 4kb for data). DOS and BIOS were, at the conceptual level, straight ripoffs from CP/M; the latter had a truly bipolar locus of control design: either it was in BIOS or BDOS, or it was in your code. This decision was carried on to DOS. Asynchronous hardware-generated interrupts were not really necessary if the hardware could provide buffering for input devices, the application had to poll or block for input anyway, so if the hardware was buffering you didn't need any interrupts to do buffering in software. This held true for both CP/M and DOS, in fact.
Lack of async I/O was what made DOS applications block on I/O. If you had a "DOS" application that appeared not to block on I/O, then said application had its own filesystem and disk drivers. I don't know how pervasive that was, but I sure had an application that had fully asynchronous access to ATA drives, floppy drives and UARTs and it did not do any BIOS calls at all, for anything besides setting initial graphics mode via a VESA call. Back then there were multiple books that dealt with internals of PC hardware, I remember the Polish series "Anatomia PC" (anatomy of PC) that had multiple editions and IIRC covered everything you needed to get that hardware flying at full potential.
Yep. TP3 would use function stubs that would check if the overlay with the function was loaded, if not it'd bring it in first, and then would call the function. Functions were grouped in overlays to basically provide manual working set control. Overlays were an all-or-nothing affair IIRC, so either an overlay could be completely in or completely out. Thus if you had a bunch of related functions, they better be in one overlay or else you'd wait long for all the disk activity. This wasn't all that bad, as it required thinking ahead and designing your code to play well with overlays. Paging-to-disk virtual memory does the same thing, but it's behind the scenes and too many people have no clue how their code is laid out in memory, and how nicely it plays along with paging...
Turbo Pascal 3 was a CP/M code base that got ported to MS/DOS, and all that "high level" I/O functionality you speak of could neatly fit into about 20 kilobytes of machine code and data space (including some room for executable programs!), whether on Z80 or 8086.
All that CP/M provided was access to files, console and printer. I have a set of CP/M 2.0 manuals within arms reach and that's all there was to it. If Turbo Pascal were to include the entirety of resident CP/M in it (BIOS + BDOS), its code size would not even double.
Hummer is not "large", at least not cargo-capacity-wise. You could fit more stuff into a Volvo 940 wagon than would fit into most SUVs. Hummer is a large SUV, but it doesn't look like it'd fit a lot of stuff. I don't know offhand if a Hummer fits a typical behemoth two-door american fridge, but it surely did fit into that 940 wagon. All it took was to fold down the rear seats and unscrew the handles from the fridge's door. Oh, and that wagon could sit seven with third row seating.
Text is not an array of numbers. That's why a lot of applications required heavy-handed porting to unicode. Text is an array of characters. I don't routinely need Chr nor Ord (nor their equivalents in any other language). Their use is pretty much limited to a somewhat hacky implementation of base conversion for I/O, and even there it's a safer bet to use a lookup array unless you really need to optimize memory use.
If you have a string and want ASCII output (or input), you use a codec to do it. Any non-trivial application written in C or C++ will not use char type to represent characters -- char is merely used to store byte-size integers (and that's only by convention), and a C opaque type or a C++ class is used for characters instead. It's a fundamentally broken assumption that characters "are" integers. They are not, they are characters for crying out loud! C code done to higher standards (say MISRA C) will use sized types like int8 anyway, and you are not supposed to find char anywhere in your code.
It's not really a normal thing to modify characters (like add/subtract/multiply, etc). In fact, it'd be most commonly an error to do so, because you're presupposing stuff about their representation. Characters are usually more correctly though of as an opaque key that's used to index various tables, and that's about it. A good compiler should be able to optimize certain things "knowing" the ASCII encoding, but that requires a compiler where it's easy to code such optimizations. Offhand I only know of one class of off-the-shelf language systems where you could easily code it up: LISP.
I've just gone through the book. That "computer" is fine, but it is a completely manual affair. I posit that all the lights and other stuff are a distraction, it'd be easier to do it on a well designed set of paper forms -- some for storing contents of memory and registers, some for performing individual operations. If all instructions are very simple, you can have one sheet where you write down clock cycle #, PC, value(s) at PC, values of inputs, work out the decode, work out output, and write that down. Any changes to ram etc. are then annotated on the ram/register sheet, perhaps with a column per each address so that you simply write down the newest value under the previous one. For tracing purposes, you could be writing clock# at which the value was written next to the value, that way your paperwork is a complete trace of execution and if there are errors you can see how they propagated and can fix them.
I think it'd be way more fun to build a very simple relay-based machine. You can still wire it point-to-point, and you can still use incandescent lamps for indicators:)
But they were both successful, and that means that they probably understand their design pretty darn well. Most programs have plenty of early failures, and those usually mean that the engineering view of things doesn't mesh with reality just yet:)
Its no great stretch of the imagination that a change in the software makes it not shut down early if flow rate drops a bit... If its going to be a total loss anyway, may as well keep burning.
It's a great stretch of imagination for anyone who has ever heard of basics of combustion. If you starve an engine for fuel, it'll run lean. Lean running engines, whether ICUs or rocket nozzles, run much hotter than they were designed for. You can easily burn through a combustion chamber and nozzle (as in melting through it) by burning lean mixture. I've seen a diesel locomotive's exhaust getting nearby stuff on fire because a fuel pump was malfunctioning and the engine was running lean. The exhaust glowed orange, whereas normally you can't see it glowing much at all.
Thus you are going from a "total loss" where the payload can safely return to earth if it was meant to do so (Progress as a whole isn't), to a real total loss where the vehicle has a good chance of actually blowing up due to what would be a designed-in disintegration of the rocket engine.
I don't think he values Jesus much at all, because, according to him, a human's life loses its value if said human is driving fast in a car and happens to have police in pursuit of them. I don't exactly recall this sort of value-of-life-relativism coming out anywhere in Jesus's philosophy... Maybe I'm just ignorant, though, maybe the unearthed some new scrolls or something.
CentOS 6 currently seriously lags in updates. I gave it a try, but then over a couple of weeks there wasn't a single new package available. Over the same time RHEL pushed out a dozen updates easy. It'd be pretty irresponsible to rely on CentOS, and anyone not understanding this is unfit for a CIO job. Two socket RHEL is a couple hundred bucks. It's money well spent. If you want to be cheap, you better compiled all RHEL released SRPMs as soon as they are available and kept your CentOS up to date that way.
The discussion of possible fakes that you provided is only superficially valid. The truth is that in any single experiment they did not thoroughly examine everything that had to be examined, and they did not isolate the system (it should run on a fixed reservoir for incoming water, an instrumented condenser for outgoing steam, etc.). All those verification experiments looked like an elementary grader's science fair project, not due diligence in anything. Outgoing steam hissing through a hose into the atmosphere? I mean, the fuck? No one in their sane mind would allow a mass release testing of any "revolutionary" heat source, unless we're talking about secondary or tertiary evaporative cooling.
The long discussion of possibilities of cheating by doing a detailed analysis of each piece of the system is essentially mental acrobatics. It looks good, but is pretty much useless other than for diversion/entertainment. There are valid ways of doing black box testing and they all imply isolation of the system, including retaining mass in all primary medium loops, and finely controlling any exchange of heat or mass with outside. Randi would have laughed them all out of the room.
Heck, the analysis seems like it was engineered to seem plausible. I wonder if whoever wrote most of it wasn't in cahoots with the artists who run the show.
Slashdot Mirror
I routinely write stuff for devices that small, and after a while you get used to it. These days I'm on a platform where 64 kilobytes is shared between code and data of up to 8 threads of execution. At least I have 500 MIPS to play with.
We passed the point where "normal" people care about execution speed a while ago. Does it matter whether your spreadsheet needs 2 milliseconds longer to calculate the results? I mean, instead of 0.2 you now need 0.202 seconds, do you notice? Do you care? Today, you can waste processing time on animating cursors and create colorful file copy animations. Why bother with optimization?
I care. I'm pissed that current, so-fast-it's-silly hardware, coupled with bloated software, provides me with a system that is less responsive than stuff we had in the 80s. Yes, I do care. Every time I see a spinning beach ball or the application is not reacting to input, I waste time. 0.2 seconds is a LONG time in terms of UI latency. It's well documented I think that this sort of a delay starts to kill productivity, never mind on-the-job satisfaction.
Moving data between RAM and CPU takes a finite and easy-to-measure amount of energy per each byte. Same goes for transfers between memory and peripherals.
Not in Pascal, not even in assembly if you were using CP/M or DOS!!! Opening a file and reading a block would probably fit in 32 bytes of machine code for both CP/M and DOS, file name excluded.
MetaWindows -- hey, I remember that. Was quite nice for what it did.
DOS did a minimal amount of stuff for the keyboard and screen IO -- those were pretty much thin wrappers around BIOS calls, merely allowing you to throw in a different driver that could do, say, terminal emulation (ansi.sys, anyone?).
Its file system implementation, at least in the early days (up to dos 3.3, as that's how far my reverse engineering went), was pretty much toy-like and sucked dick, so to speak.
DOS and BIOS were designed for single-threaded programming, even though there was plenty of knowledge back then from UNIX as to how to design a compact system that would allow if not full-blown multiprocessing, then at least asynchronous I/O. It didn't require any rocket science coding either, I routinely do cooperative, priority-driven preemptive multitasking on hardware with 80s-era memory sizes (48kb for code, 4kb for data). DOS and BIOS were, at the conceptual level, straight ripoffs from CP/M; the latter had a truly bipolar locus of control design: either it was in BIOS or BDOS, or it was in your code. This decision was carried on to DOS. Asynchronous hardware-generated interrupts were not really necessary if the hardware could provide buffering for input devices, the application had to poll or block for input anyway, so if the hardware was buffering you didn't need any interrupts to do buffering in software. This held true for both CP/M and DOS, in fact.
Lack of async I/O was what made DOS applications block on I/O. If you had a "DOS" application that appeared not to block on I/O, then said application had its own filesystem and disk drivers. I don't know how pervasive that was, but I sure had an application that had fully asynchronous access to ATA drives, floppy drives and UARTs and it did not do any BIOS calls at all, for anything besides setting initial graphics mode via a VESA call. Back then there were multiple books that dealt with internals of PC hardware, I remember the Polish series "Anatomia PC" (anatomy of PC) that had multiple editions and IIRC covered everything you needed to get that hardware flying at full potential.
Yep. TP3 would use function stubs that would check if the overlay with the function was loaded, if not it'd bring it in first, and then would call the function. Functions were grouped in overlays to basically provide manual working set control. Overlays were an all-or-nothing affair IIRC, so either an overlay could be completely in or completely out. Thus if you had a bunch of related functions, they better be in one overlay or else you'd wait long for all the disk activity. This wasn't all that bad, as it required thinking ahead and designing your code to play well with overlays. Paging-to-disk virtual memory does the same thing, but it's behind the scenes and too many people have no clue how their code is laid out in memory, and how nicely it plays along with paging...
Turbo Pascal 3 was a CP/M code base that got ported to MS/DOS, and all that "high level" I/O functionality you speak of could neatly fit into about 20 kilobytes of machine code and data space (including some room for executable programs!), whether on Z80 or 8086.
All that CP/M provided was access to files, console and printer. I have a set of CP/M 2.0 manuals within arms reach and that's all there was to it. If Turbo Pascal were to include the entirety of resident CP/M in it (BIOS + BDOS), its code size would not even double.
Hummer is not "large", at least not cargo-capacity-wise. You could fit more stuff into a Volvo 940 wagon than would fit into most SUVs. Hummer is a large SUV, but it doesn't look like it'd fit a lot of stuff. I don't know offhand if a Hummer fits a typical behemoth two-door american fridge, but it surely did fit into that 940 wagon. All it took was to fold down the rear seats and unscrew the handles from the fridge's door. Oh, and that wagon could sit seven with third row seating.
I don't think that the GUI for Turbo Pascal sucked all that much, compared to what else was available in the same price range.
I guess C's syntax makes it more error prone if anything, since you have a bug. 2nd line of C should be:
p = (int*) malloc(sizeof(*p));
Text is not an array of numbers. That's why a lot of applications required heavy-handed porting to unicode. Text is an array of characters. I don't routinely need Chr nor Ord (nor their equivalents in any other language). Their use is pretty much limited to a somewhat hacky implementation of base conversion for I/O, and even there it's a safer bet to use a lookup array unless you really need to optimize memory use.
If you have a string and want ASCII output (or input), you use a codec to do it. Any non-trivial application written in C or C++ will not use char type to represent characters -- char is merely used to store byte-size integers (and that's only by convention), and a C opaque type or a C++ class is used for characters instead. It's a fundamentally broken assumption that characters "are" integers. They are not, they are characters for crying out loud! C code done to higher standards (say MISRA C) will use sized types like int8 anyway, and you are not supposed to find char anywhere in your code.
It's not really a normal thing to modify characters (like add/subtract/multiply, etc). In fact, it'd be most commonly an error to do so, because you're presupposing stuff about their representation. Characters are usually more correctly though of as an opaque key that's used to index various tables, and that's about it. A good compiler should be able to optimize certain things "knowing" the ASCII encoding, but that requires a compiler where it's easy to code such optimizations. Offhand I only know of one class of off-the-shelf language systems where you could easily code it up: LISP.
I've just gone through the book. That "computer" is fine, but it is a completely manual affair. I posit that all the lights and other stuff are a distraction, it'd be easier to do it on a well designed set of paper forms -- some for storing contents of memory and registers, some for performing individual operations. If all instructions are very simple, you can have one sheet where you write down clock cycle #, PC, value(s) at PC, values of inputs, work out the decode, work out output, and write that down. Any changes to ram etc. are then annotated on the ram/register sheet, perhaps with a column per each address so that you simply write down the newest value under the previous one. For tracing purposes, you could be writing clock# at which the value was written next to the value, that way your paperwork is a complete trace of execution and if there are errors you can see how they propagated and can fix them.
I think it'd be way more fun to build a very simple relay-based machine. You can still wire it point-to-point, and you can still use incandescent lamps for indicators :)
Dead man switch: an automatic story post to slashdot?
Nope. If you follow the right process while developing -- like the team that did shuttle's software -- you won't have such problems.
Dr Bob is now AC?
This is quite insightful. Thanks!
Nope. You have blind faith with people who will fuck you over if it's politically expedient.
But they were both successful, and that means that they probably understand their design pretty darn well. Most programs have plenty of early failures, and those usually mean that the engineering view of things doesn't mesh with reality just yet :)
Its no great stretch of the imagination that a change in the software makes it not shut down early if flow rate drops a bit... If its going to be a total loss anyway, may as well keep burning.
It's a great stretch of imagination for anyone who has ever heard of basics of combustion. If you starve an engine for fuel, it'll run lean. Lean running engines, whether ICUs or rocket nozzles, run much hotter than they were designed for. You can easily burn through a combustion chamber and nozzle (as in melting through it) by burning lean mixture. I've seen a diesel locomotive's exhaust getting nearby stuff on fire because a fuel pump was malfunctioning and the engine was running lean. The exhaust glowed orange, whereas normally you can't see it glowing much at all.
Thus you are going from a "total loss" where the payload can safely return to earth if it was meant to do so (Progress as a whole isn't), to a real total loss where the vehicle has a good chance of actually blowing up due to what would be a designed-in disintegration of the rocket engine.
Look around. Get a dedicated person to learn the ropes with you. There's plenty of intelligent people out there looking for work.
I don't think he values Jesus much at all, because, according to him, a human's life loses its value if said human is driving fast in a car and happens to have police in pursuit of them. I don't exactly recall this sort of value-of-life-relativism coming out anywhere in Jesus's philosophy... Maybe I'm just ignorant, though, maybe the unearthed some new scrolls or something.
CentOS 6 currently seriously lags in updates. I gave it a try, but then over a couple of weeks there wasn't a single new package available. Over the same time RHEL pushed out a dozen updates easy. It'd be pretty irresponsible to rely on CentOS, and anyone not understanding this is unfit for a CIO job. Two socket RHEL is a couple hundred bucks. It's money well spent. If you want to be cheap, you better compiled all RHEL released SRPMs as soon as they are available and kept your CentOS up to date that way.
Sweet dreams, AC.
The discussion of possible fakes that you provided is only superficially valid. The truth is that in any single experiment they did not thoroughly examine everything that had to be examined, and they did not isolate the system (it should run on a fixed reservoir for incoming water, an instrumented condenser for outgoing steam, etc.). All those verification experiments looked like an elementary grader's science fair project, not due diligence in anything. Outgoing steam hissing through a hose into the atmosphere? I mean, the fuck? No one in their sane mind would allow a mass release testing of any "revolutionary" heat source, unless we're talking about secondary or tertiary evaporative cooling.
The long discussion of possibilities of cheating by doing a detailed analysis of each piece of the system is essentially mental acrobatics. It looks good, but is pretty much useless other than for diversion/entertainment. There are valid ways of doing black box testing and they all imply isolation of the system, including retaining mass in all primary medium loops, and finely controlling any exchange of heat or mass with outside. Randi would have laughed them all out of the room.
Heck, the analysis seems like it was engineered to seem plausible. I wonder if whoever wrote most of it wasn't in cahoots with the artists who run the show.