Re:What Real Time is and what you can do with it.
on
RT Linux Patches
·
· Score: 0
For the more techies: this is not like priorities in non-rt-kernels where an higher priority results in more timeslices in the round robin algorithm, it means that it isn't interrupted until it reaches a certain 'done'-state. And if a process depends on an other process (radar automatic pilot relationship-like) that process will be run prior to the automatic pilot process, to assure the automatic pilot gets new data, and no old data or old/new mixed data.
My "techie" friend, RTOSes have, if you wish, and usually as default, round robin scheduling policies. A RTOS, and by extension, any OS, doesn't cares about your application, his main target it is to comply with their white paper specification. Id est, if the vendor say that their RTOS have a list of N response times for N circumstances, it is your responsability to solve your problem with the RTOS as a tool. The main and only difference between a RTOS and a non RTOS is that a RTOS gives to you a list of acotated response times related to the OS responsability, don't care if the units are microseconds or years. Of course, as example, if you have to deal with servomechanisms you'll need, at least millisecond precission. The quantification of the time response for a RTOS is the variable that allow that you could say "this RTOS, as tool, will work with my software application to solve the requested engineering problem".
Re:Desktop Usage? Why not?!
on
RT Linux Patches
·
· Score: 4, Interesting
Actually, there are RTOS UNIXes running desktops. From three years ago, I'm used to run the Posix Desktop over LynxOS 3.0.1 (nowdays on 4.0.0), running gvim, emacs, xmame, and so on. The only missing thing was USB and sound card support (still not supported on v. 4.0.0). There is also XFree support, at least for LynxOS, but may be too for QNX et al.
There are, of course, disavantatges, you can not archieve the same disk throughput on current RTOS compared to Linux or Windows. From my experience, both ethernet and IDE throughput it's far from being optimal on a RTOS (think about 60-80%). But that it is commonsense, if you want kick ass response times, you'll lose a bit of throughput and viceversa.
There is other important points, usually, on RTOS the disk-cache has a fixed size, processes are limited to a relatively low number (usually 100 to 500), and many other limitations.
The resume it's quite easy, if you want to have a RTOS you should be sure you have, at least:
1) Preemptible kernel
2) Inverted priority detection (to avoid thread stalls; this point it is not 100% solved on most commercial RTOS)
3) Acotated resources
3.1) Deterministic disk cache (usually fixed length on most -current- implementations)
3.2) Limited process handling (that point may will be specially good for Linux and the O(1) scheduler, as other RTOS have poorest scheduling scheemes; could be amazing having thousands of threads without penalization... beating commercial RTOSes (!))
(This thread it's amazing, but I'm tired; 2:30 am here, I have to leave without adding a more complete comment, sorry).
First of all, RTLinux doesn't mean "Linux having RTOS" but "some weird trick^H^H^H^H^H^H^H^H^H^H^H software that runs Linux on his spare time, able to comunicate with it". After this puntualization, it is fair to say that RTLinux it is useful for a wide spread of applications requiring not only real time response but also very short response time; i.e., on 10-20 us requeriments, RTLinux it is still better than VxWorks or LynxOS, as has a very thin harness. By the way, in the real world, these critical tasks are driven by little MCUs (8 or 16 bit ones), not by an powerful 32 bit system. For 32/64 bits systems, driven by a UNIX (or UNIX-like) RTOS (real time operating system), you should have enough with 50 us to 10ms respose times.
Commercial UNIXes, as LynxOS, are able to give to you a table with a relation of response times for every aspect of the OS (scheduling, OS primitives, IRQ dispatching, etc.).
From my point of view, Linux has two major handicaps:
1) Archieve fully POSIX compliance in both process/thread identification/handling and inprocess signal routing (actually it is painful to migrate complex POSIX apps to Linux).
2) True hard real time response archievement; after this goal, winning the "RTOS" label (and bringing joy to my heart; sorry for the subjective parenthesed comentary).
That's the first rule of engineering, adjust the hardware to your functional requeriments as close as possible. Computation power excess it's only good when it comes for free and has no extra power compsumption.
For more than 100 units it is usually better to pay an experimented engineer rather than pay a beginner to program a 32 bit MCU in any strange/weird high level language, you'll save a bit on sofware but will lose money on every unit above 100.
I agree. Some extra wood:.NET architecture it's vulnerable, by design:
1) plenty redundance
2) developer forced to do weird/unorthodox tricks
3) too much centralization
4) * add your observation here *
I don't like.NET, not just by MS, but because it's very unestable and has a dirty/precipitated design (by te way, I admit that their C++ compiler it's fairly good; although they "get inspired" by GNU on the exception handling between VC5 and VC6... curious).
"Is there an existing programming language that you would recommend for the implementation of operating systems?"
Would you recommend creating a new language for a new OS, as was done with Unix?
Right, no one said anything about C++, but, as almost everything, new solutions come along with new needs. At 60-70's the only one real option for OS development was machine code, assembly in best case. The next step, for OS development was avoid assembly, using a "not so low level" language, C was a nice option, still codeveloped/coevolutioned with UNIX.
Why I said C++? Just because there is a lot of people who think that it is the next step. I disagreed in my previous case for the OS case; for applications, ok, It's how I survive, still better that do it in java. Sorry if you were speaking about a "new and superfashion" new language for a metrocool OS, or whatever. Regards.
Most graphic cards are in a big trouble on data integrity, only SRAM area is 100% sure (you'll be glad about your graphic DRAM behaviour on most cards). If you can not be 100% sure that all the bits are coherent, you'll be in a trouble if you want to do some "sensible" processing that could depend on just one bit (both raw audio and video are relatively inmune to these faults, but what about compressed/processed data to be retrieved?!).
More or less rethorical, I see this suing hit/act just as a reply to these companies: they are two of the few that sell MPEG2+MPEG4+ARM on-a-chip solution, allowing the user to watch DivX and XVID streams (I have one witch includes one Mediatek 1389GE, the whole aparatus was just 50 euro (16% VAT included)).
May be this was just a desperate action, stopping people enjoing 5 or 6 films on a DVD-R disk in a row. What a paradise.
Google must play in these arena, as they will have millions of e-mail users and the whole world using his search engine, due to that, usually, when a posibility seems to be feasible, it become a reality, via inertia unstoppable fact.
The good life is one inspired by love and guided by knowledge. Bertrand Russell.
GPL could be in a big trouble without IBM or any other powerful partner; as example as things work in the world today, SCO could argue that GNU GPL and Linux as GPL'ed soft are the evil, potential massive destruction software, etc. (or acuse them of comunists or whatever other stupidity). Nowdays, still the truth suffers when a non-sense deep analysis is done by { stupid | unmoral | unethic } people.
Personally, still the fact that IBM spends tons of money on investigation, and it is good, etc., I don't blindy trust them; I can not stop watching potential IBM monopolistic/tyranic steps, do you remember 80's?
For sure. My bet is that Google will be adquired by M$. I hope they still keep Linux for running their search engine (as yahoo does with FreeBSD). The power, if exist, will be used to keep it's own existence alive, usually.
I agree. Please, future involved lawyers, take note: this forum thread it is a good resource to build a good defence.
Some IT milestones for the humanity:
-CPU in-a-chip: cheap systems for the masses
-Connectivity (from serial to network hardware and protocols): mid-litle bussiness increased productivity
-Berkeley and TCP-IP: great system infrastructure
-Internet: http protocol it is used for *knowledge sharing*.
-P2P: great way for *content sharing*
Things that are good for the humanity, simply, shouldn't be illegal. Of course, content makers should have incomes, common sense incomes. A product should be quoted as amortized as long it has profit enough for its maker, then, provided almost free just with a % of your ISP receipt if you download the content online. P2P networks are often used to retrieve quite old content, not just to download the last teenager music crap.
Closing P2P, you may help to increase 2% content makers incomes (not much more, people *still* buys lots of cds, dvds and books), but you hurt in a high grade human happiness (to live without P2P, please read "The Conquest of Happiness" by Bertrand Russell). To have almost instant access to contents it is, simply, a miracle.
XP embedded is quite robust due to its scalability.
That it is, simply, not true. You can have an scalable but non robust system (prove: exercise).
Serious embedded and proven stable systems (LynxOS, VxWorks, etc) are UNIX-based ones, requiring as little as 3MB of disk for a whole system (complete UNIX system, Posix API, TCP-IP, filesystems, and many other cool things). The other approach is to use a 68K or V25 board with no OS, just with an interrupt dispatcher, a "for" and N functions for launching the task and so on.
Anyway, the point is that a system that potentially has to be precise in servo-control, take real-time measures can not run *relliable* on a non real-time system (XP's, NT's were not designed for time-critical applications, and it is proven in the real world, still with 3GHz CPU's). In Windows NT's, both process scheduling and thread switching it is simply not good enought for critical real-time applications (may be these people doesn't care if their plane crash by a faulty design or just by a code retard related to their "cute" XP system).
Anyway, for that problem you *don't* need nor that CPU (800Mhz (!)) nor the storage (1GB (!)), nor the poor language ("c#" aka "c sharp"). From my point of view, it is an absolute nonsense for real-life industrial use.
Fedora Core 2, and Linux 2.6 in general, doesn't work at all in Virtual PC 2004; the reason: the Linux 2.6 kernel uses "code morphing" techniques (i.e. code that performs write operations to code regions, and may be that crashes the "virtualization" (may be due to some TLB misscontrol/missinterpretation, etc)).
Ah! Fedora Core 2 is installed properly in VPC2004 and VMWare... because the instalation phase runs in a 2.4 kernel (!).
VM Ware runs Linux 2.6, but not as well as it runs 2.4; the Linux 2.6 "code morphing" affects seriously also to the VMW guys. Linux 2.6 it is a good host for emulation, but not a good one to "virtualize"; I hope It will be fixed soon.
P.S. don't bore too much Mr Fabrice Bellard, let him work. Don't you remember LZexe? He programmed it when he was almost a teenager (!) Expect great things for Wine + QEmu, it is not vaporware.
May be it is slow, but is the only one if you want to run Lynx OS (at least since version 5, before the MS era), with both VGA and ethernet support (VMWare crashes).
Why not? Sun did and does a good job in the IT industry: still at expensive prices, they provide robust hardware and good software.
It is not the first deployment done by Sun to avoid it's more or less unavoidable bankrupt, remember Java and Star Office. They, as every company, are legitimated to try to survive, moreover when they do *positive* and *useful* products. I prefer to think M$ as evil rather than Sun, still when both are quite 80's penguin dressed/fashioned people.
Anyway, some b*st*rds are converting Linux into an obscure and unconfigurable thing, remembering Tanembaum and his KISS acronym: keep it simple, stupid (goes for SUSE and Red Hat). Solaris IS still enough simple, almost spartane; that spartanness could be a good for the hypothetical/future SUSE.
Curious about pointing as "funny" the previous message, it was telling a fact.
Anyway, the Sega Dreamcast has a poor integer performing main CPU (Hitachi SH4, 200Mhz, two-way superscalar), still in 1998, for a RISC CPU. Needless to say that has a good floating point performance, due to SIMD and other DSP goodies. The graphic chip (PVR, from NEC) was a 'state of the art' development, light years ahead from the -in comparation- poor SH4 CPU.
I share the "love" for the Dreamcast, etc, may be just because it's a lot easier to program than a PS2 (with a R5900+2xVU triple monster doing FP fmacs, and with a fast but weird/ugly graphic chip; still I prefer the "triple team" of the PS2 rather than the cutie but always fatigued DC's SH4).
By the way, I find quite fool this thread: are three or four new -and poor- emulator *ports* for the DC a quite interesting thing? At least, not for me. Quite sad.
Without the network adaptor (aka "broadband adaptor", silly euphemism), still with a good Linux 2.6 port, I would not be easy for me unpack/rescue my DC from his box.
Excuse me, but programmable circuits are not a new thing: as example, remember Altera PLA's, etc. The big problem of the "good old known" programmable circuits is that it is required a lot more space than for non programable ones, i.e. you could need 100 million of transistors to "program" a i386 with no cache, and of course, running at a much lower clock that the main core (think about clock propagation in a programable circuit, about 10x slower).
Anyway, thinking about talented IBM people, may be they have reached "few overhead" [re?]programming techniques, being able to use these kind of techniques into the { mainstream | general purpose } market. Maybe the point/key is the programmable circuit technology they used: if it is nearby the factory-hardwired one, we have not only a functional unit defective repath, but also some free drawboard space to [re?]program some nice ops, hopefully running at 80-90% speed respect to the used gate (due to the extra glue involved).
P.S. needless to say about my poor english, sorry.
Slashdot Mirror
For the more techies: this is not like priorities in non-rt-kernels where an higher priority results in more timeslices in the round robin algorithm, it means that it isn't interrupted until it reaches a certain 'done'-state. And if a process depends on an other process (radar automatic pilot relationship-like) that process will be run prior to the automatic pilot process, to assure the automatic pilot gets new data, and no old data or old/new mixed data.
My "techie" friend, RTOSes have, if you wish, and usually as default, round robin scheduling policies. A RTOS, and by extension, any OS, doesn't cares about your application, his main target it is to comply with their white paper specification. Id est, if the vendor say that their RTOS have a list of N response times for N circumstances, it is your responsability to solve your problem with the RTOS as a tool. The main and only difference between a RTOS and a non RTOS is that a RTOS gives to you a list of acotated response times related to the OS responsability, don't care if the units are microseconds or years. Of course, as example, if you have to deal with servomechanisms you'll need, at least millisecond precission. The quantification of the time response for a RTOS is the variable that allow that you could say "this RTOS, as tool, will work with my software application to solve the requested engineering problem".
Actually, there are RTOS UNIXes running desktops. From three years ago, I'm used to run the Posix Desktop over LynxOS 3.0.1 (nowdays on 4.0.0), running gvim, emacs, xmame, and so on. The only missing thing was USB and sound card support (still not supported on v. 4.0.0). There is also XFree support, at least for LynxOS, but may be too for QNX et al.
There are, of course, disavantatges, you can not archieve the same disk throughput on current RTOS compared to Linux or Windows. From my experience, both ethernet and IDE throughput it's far from being optimal on a RTOS (think about 60-80%). But that it is commonsense, if you want kick ass response times, you'll lose a bit of throughput and viceversa.
There is other important points, usually, on RTOS the disk-cache has a fixed size, processes are limited to a relatively low number (usually 100 to 500), and many other limitations.
The resume it's quite easy, if you want to have a RTOS you should be sure you have, at least:
1) Preemptible kernel
2) Inverted priority detection (to avoid thread stalls; this point it is not 100% solved on most commercial RTOS)
3) Acotated resources
3.1) Deterministic disk cache (usually fixed length on most -current- implementations)
3.2) Limited process handling (that point may will be specially good for Linux and the O(1) scheduler, as other RTOS have poorest scheduling scheemes; could be amazing having thousands of threads without penalization... beating commercial RTOSes (!))
(This thread it's amazing, but I'm tired; 2:30 am here, I have to leave without adding a more complete comment, sorry).
First of all, RTLinux doesn't mean "Linux having RTOS" but "some weird trick^H^H^H^H^H^H^H^H^H^H^H software that runs Linux on his spare time, able to comunicate with it". After this puntualization, it is fair to say that RTLinux it is useful for a wide spread of applications requiring not only real time response but also very short response time; i.e., on 10-20 us requeriments, RTLinux it is still better than VxWorks or LynxOS, as has a very thin harness. By the way, in the real world, these critical tasks are driven by little MCUs (8 or 16 bit ones), not by an powerful 32 bit system. For 32/64 bits systems, driven by a UNIX (or UNIX-like) RTOS (real time operating system), you should have enough with 50 us to 10ms respose times.
Commercial UNIXes, as LynxOS, are able to give to you a table with a relation of response times for every aspect of the OS (scheduling, OS primitives, IRQ dispatching, etc.).
From my point of view, Linux has two major handicaps:
1) Archieve fully POSIX compliance in both process/thread identification/handling and inprocess signal routing (actually it is painful to migrate complex POSIX apps to Linux).
2) True hard real time response archievement; after this goal, winning the "RTOS" label (and bringing joy to my heart; sorry for the subjective parenthesed comentary).
That's the first rule of engineering, adjust the hardware to your functional requeriments as close as possible. Computation power excess it's only good when it comes for free and has no extra power compsumption.
For more than 100 units it is usually better to pay an experimented engineer rather than pay a beginner to program a 32 bit MCU in any strange/weird high level language, you'll save a bit on sofware but will lose money on every unit above 100.
I agree. Some extra wood: .NET architecture it's vulnerable, by design:
.NET, not just by MS, but because it's very unestable and has a dirty/precipitated design (by te way, I admit that their C++ compiler it's fairly good; although they "get inspired" by GNU on the exception handling between VC5 and VC6... curious).
1) plenty redundance
2) developer forced to do weird/unorthodox tricks
3) too much centralization
4) * add your observation here *
I don't like
"Is there an existing programming language that you would recommend for the implementation of operating systems?"
Would you recommend creating a new language for a new OS, as was done with Unix?
Right, no one said anything about C++, but, as almost everything, new solutions come along with new needs. At 60-70's the only one real option for OS development was machine code, assembly in best case. The next step, for OS development was avoid assembly, using a "not so low level" language, C was a nice option, still codeveloped/coevolutioned with UNIX.
Why I said C++? Just because there is a lot of people who think that it is the next step. I disagreed in my previous case for the OS case; for applications, ok, It's how I survive, still better that do it in java. Sorry if you were speaking about a "new and superfashion" new language for a metrocool OS, or whatever. Regards.
Well written C has no parangon when programming an OS. Why?
-It's a pretty simple and language (try compare the complete C BNF vs c. C++ BNF)
-Modern C, as rich C++ without classes, it's fairly flexible
-C compilers are, usually, safers than C++ ones (this applies also for gnu cc and gnu cppc)
-C is alive, being updated; growing in just the common sense, without absurd and unuseful features (what about C++ massive redundancy?)
-C fits entirely on your head, C++ don't
- * add your contribution, with love, here *
1. Quake 2. Shake it up babe 3. Profit!
1. Volcano
2. Shake it up babe
3. Profit!
Most graphic cards are in a big trouble on data integrity, only SRAM area is 100% sure (you'll be glad about your graphic DRAM behaviour on most cards). If you can not be 100% sure that all the bits are coherent, you'll be in a trouble if you want to do some "sensible" processing that could depend on just one bit (both raw audio and video are relatively inmune to these faults, but what about compressed/processed data to be retrieved?!).
Yes, VB it is a clear management idiot proof.
More or less rethorical, I see this suing hit/act just as a reply to these companies: they are two of the few that sell MPEG2+MPEG4+ARM on-a-chip solution, allowing the user to watch DivX and XVID streams (I have one witch includes one Mediatek 1389GE, the whole aparatus was just 50 euro (16% VAT included)).
May be this was just a desperate action, stopping people enjoing 5 or 6 films on a DVD-R disk in a row. What a paradise.
Google must play in these arena, as they will have millions of e-mail users and the whole world using his search engine, due to that, usually, when a posibility seems to be feasible, it become a reality, via inertia unstoppable fact.
The good life is one inspired by love and guided by knowledge. Bertrand Russell.
GPL could be in a big trouble without IBM or any other powerful partner; as example as things work in the world today, SCO could argue that GNU GPL and Linux as GPL'ed soft are the evil, potential massive destruction software, etc. (or acuse them of comunists or whatever other stupidity). Nowdays, still the truth suffers when a non-sense deep analysis is done by { stupid | unmoral | unethic } people.
Personally, still the fact that IBM spends tons of money on investigation, and it is good, etc., I don't blindy trust them; I can not stop watching potential IBM monopolistic/tyranic steps, do you remember 80's?
For sure. My bet is that Google will be adquired by M$. I hope they still keep Linux for running their search engine (as yahoo does with FreeBSD). The power, if exist, will be used to keep it's own existence alive, usually.
I agree. Please, future involved lawyers, take note: this forum thread it is a good resource to build a good defence.
Some IT milestones for the humanity:
-CPU in-a-chip: cheap systems for the masses
-Connectivity (from serial to network hardware and protocols): mid-litle bussiness increased productivity
-Berkeley and TCP-IP: great system infrastructure
-Internet: http protocol it is used for *knowledge sharing*.
-P2P: great way for *content sharing*
Things that are good for the humanity, simply, shouldn't be illegal. Of course, content makers should have incomes, common sense incomes. A product should be quoted as amortized as long it has profit enough for its maker, then, provided almost free just with a % of your ISP receipt if you download the content online. P2P networks are often used to retrieve quite old content, not just to download the last teenager music crap.
Closing P2P, you may help to increase 2% content makers incomes (not much more, people *still* buys lots of cds, dvds and books), but you hurt in a high grade human happiness (to live without P2P, please read "The Conquest of Happiness" by Bertrand Russell). To have almost instant access to contents it is, simply, a miracle.
XP embedded is quite robust due to its scalability.
That it is, simply, not true. You can have an scalable but non robust system (prove: exercise).
Serious embedded and proven stable systems (LynxOS, VxWorks, etc) are UNIX-based ones, requiring as little as 3MB of disk for a whole system (complete UNIX system, Posix API, TCP-IP, filesystems, and many other cool things). The other approach is to use a 68K or V25 board with no OS, just with an interrupt dispatcher, a "for" and N functions for launching the task and so on.
Anyway, the point is that a system that potentially has to be precise in servo-control, take real-time measures can not run *relliable* on a non real-time system (XP's, NT's were not designed for time-critical applications, and it is proven in the real world, still with 3GHz CPU's). In Windows NT's, both process scheduling and thread switching it is simply not good enought for critical real-time applications (may be these people doesn't care if their plane crash by a faulty design or just by a code retard related to their "cute" XP system).
Anyway, for that problem you *don't* need nor that CPU (800Mhz (!)) nor the storage (1GB (!)), nor the poor language ("c#" aka "c sharp"). From my point of view, it is an absolute nonsense for real-life industrial use.
Fedora Core 2, and Linux 2.6 in general, doesn't work at all in Virtual PC 2004; the reason: the Linux 2.6 kernel uses "code morphing" techniques (i.e. code that performs write operations to code regions, and may be that crashes the "virtualization" (may be due to some TLB misscontrol/missinterpretation, etc)).
Ah! Fedora Core 2 is installed properly in VPC2004 and VMWare... because the instalation phase runs in a 2.4 kernel (!).
VM Ware runs Linux 2.6, but not as well as it runs 2.4; the Linux 2.6 "code morphing" affects seriously also to the VMW guys. Linux 2.6 it is a good host for emulation, but not a good one to "virtualize"; I hope It will be fixed soon.
P.S. don't bore too much Mr Fabrice Bellard, let him work. Don't you remember LZexe? He programmed it when he was almost a teenager (!) Expect great things for Wine + QEmu, it is not vaporware.
May be it is slow, but is the only one if you want to run Lynx OS (at least since version 5, before the MS era), with both VGA and ethernet support (VMWare crashes).
Why not? Sun did and does a good job in the IT industry: still at expensive prices, they provide robust hardware and good software.
It is not the first deployment done by Sun to avoid it's more or less unavoidable bankrupt, remember Java and Star Office. They, as every company, are legitimated to try to survive, moreover when they do *positive* and *useful* products. I prefer to think M$ as evil rather than Sun, still when both are quite 80's penguin dressed/fashioned people.
Anyway, some b*st*rds are converting Linux into an obscure and unconfigurable thing, remembering Tanembaum and his KISS acronym: keep it simple, stupid (goes for SUSE and Red Hat). Solaris IS still enough simple, almost spartane; that spartanness could be a good for the hypothetical/future SUSE.
Curious about pointing as "funny" the previous message, it was telling a fact.
Anyway, the Sega Dreamcast has a poor integer performing main CPU (Hitachi SH4, 200Mhz, two-way superscalar), still in 1998, for a RISC CPU. Needless to say that has a good floating point performance, due to SIMD and other DSP goodies. The graphic chip (PVR, from NEC) was a 'state of the art' development, light years ahead from the -in comparation- poor SH4 CPU.
I share the "love" for the Dreamcast, etc, may be just because it's a lot easier to program than a PS2 (with a R5900+2xVU triple monster doing FP fmacs, and with a fast but weird/ugly graphic chip; still I prefer the "triple team" of the PS2 rather than the cutie but always fatigued DC's SH4).
By the way, I find quite fool this thread: are three or four new -and poor- emulator *ports* for the DC a quite interesting thing? At least, not for me. Quite sad.
Without the network adaptor (aka "broadband adaptor", silly euphemism), still with a good Linux 2.6 port, I would not be easy for me unpack/rescue my DC from his box.
Excuse me, but programmable circuits are not a new thing: as example, remember Altera PLA's, etc. The big problem of the "good old known" programmable circuits is that it is required a lot more space than for non programable ones, i.e. you could need 100 million of transistors to "program" a i386 with no cache, and of course, running at a much lower clock that the main core (think about clock propagation in a programable circuit, about 10x slower).
Anyway, thinking about talented IBM people, may be they have reached "few overhead" [re?]programming techniques, being able to use these kind of techniques into the { mainstream | general purpose } market. Maybe the point/key is the programmable circuit technology they used: if it is nearby the factory-hardwired one, we have not only a functional unit defective repath, but also some free drawboard space to [re?]program some nice ops, hopefully running at 80-90% speed respect to the used gate (due to the extra glue involved).
P.S. needless to say about my poor english, sorry.