Jihad needs scientists
in [Design]
|
From: jmfbahciv on 16 Feb 2007 09:07 In article <er45hl$pkf$1(a)jasen.is-a-geek.org>, jasen <jasen(a)free.net.nz> wrote: >On 2007-02-15, Ken Smith <kensmith(a)green.rahul.net> wrote: > >> The DOS mind set was to only do one thing at a time. Some bits of later >> versions looked like multitasking was intended but abandoned. Even very >> later versions save registers into code space instead of onto the stack. > >I read that there was a multitasking dos released by Microsoft in >Europe. and then there's Deskview and I think Digital Research had >a go at multitasking dos too. > >I played with something called multidos (I think it) was shareware or >freeware and faked multitasking somehow. There is a huge difference between tasking and being able to interrupt any task at any time and resuming it seamlessly later and not being able to start another task until the previous one is completely finished including EOFing the files. /BAH
From: Ken Smith on 16 Feb 2007 09:18 In article <er440c$p85$1(a)jasen.is-a-geek.org>, jasen <jasen(a)free.net.nz> wrote: [....] >It's a matter of principle not of pragmatism. > >Why pollute a linux machine with some other operating system... It isn't exactly polluting it when you run DOS under Bochs or dowemu. I still have quite a bit of code that needs to run under DOS. Because linux does a much better job of running DOS than XP or Vista, for me linux is the better answer by far. I also get the advantage of an OS that doesn't crash or get viruses etc. > >Bye. > Jasen -- -- kensmith(a)rahul.net forging knowledge
From: jmfbahciv on 16 Feb 2007 09:10 In article <er45sh$pkf$2(a)jasen.is-a-geek.org>, jasen <jasen(a)free.net.nz> wrote: >On 2007-02-12, Ken Smith <kensmith(a)green.rahul.net> wrote: >>>> You had to load the CX register to do a LOOP. >>> >>>What's LOOP got to do with anything? >> >> You haven't been following the discussion. I used the case of a REP >> prefix used inside a loop as the example of why the 8086's instruction set >> was so poorly designed. The CX and the REP both use the CX so the CX must >> be loaded for the REP inside the loop. This means that the current CX >> contents must be saved, the CX loaded, the REP done and the CX restored. >> This is a lot of extra work. > >It's less work to just use something else to hold the loop count Well, that depends on what the hardware has to do for you to change that "something else". >and use DEC and JNZ in place of LOOP (faster too since 80486) > >One of the other registers or [bp+N] is often a good choice >(for apropriate values of N) Snort. Don't you just love that "appropriate values of N"? It implies you have to check it each and every time. /BAH
From: Ken Smith on 16 Feb 2007 09:38 In article <er48ge$8qk_001(a)s897.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <er1rfs$rie$2(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [....] >>I know you can't view the web. The links point to some cute devices that >>are nothing like the channel controllers on the IBM360. One does wonder >>why MissingProng would have included them in his post. > >Hardware is not my area of expertise. Our computing biz had started >to manufacture "smart" controllers in the early 80s. I still have >mixed feeling about offloading that into the controllers. However, >the fad was distributed processing at the time and that was one >way to distribute it. The idea of moving the donkey work of file I/O onto some other processor is a sound one. The processor needed to manage I/O can be a much simpler one. The data can be DMA transfered into a shared RAM area or moved to the main RAM when the process is complete. This means that no bus cycles on the main CPU's bus are wasted on managing the operation. The idea doubly makes sense when you have a multitasking OS and a pipelined CPU. If you can avoid the extra interrupts at the CPU, you can prevent disk I/O from seriously slowing other tasks. > >> >>It seems that Intel doesn't make the 8089 anymore. Something that evolved >>from it could be a good thing to have in the modern computers. > >Be careful here. You have a unique view of what hardware should do >for you; krw has a very different view of what the hardware should >do. He disagrees with me and therefor is obviously wrong. [......] >> Perhaps it >>will be multiCPU machines that will be the next break through in general >>purpose computing. > >That's already been done. That's not a breakthrough. I think you misunderstood the meaning of that. Yes there are some multiCPU machines out there but in the general purpose market, the "multi" means a small number and not the 32K processor system I was thinking of. > >> There are already some machines for special purposes >>that have 32K processors in them. > >What would be the best thing for the computer system biz right now >is for the hardware to hit the brick wall. Then resources will >be available for decent coding work. At the moment any slop >is acceptable because there is enough hardware capacity to handle >it. Perhaps a soft wall would be better. When the cost of more speed starts to rise, more money for good programmers will make sense. Unfortunately, I'm not sure the US is creating a new batch of good programmers. >>I think that Linux has reached the point where it is good enough for all >>practical purposes. > >Nope. It is not a product (in the sense that we called things >a product). It is still a toy; it has a little bit more growing >up to do. I disagree. The OS portion of a Linux system works quite well. >> Chances are a break through in the hardware will be >>the next big thing. > >GAWD. I HOPE NOT. All we've been having is hardware break >throughs. This has all had the direct effect of coding slop. We seem to differ about what a breakthrough is. I see what has been happening as just more of the same. Even the idea of a dual core machine has been around for a long time. A breakthrough would be something totally different. The Transputer comes to mind as an example of the sort of difference I'm thinking of. > >> As OSes go it is fairly good. Unlike Windows, it can >>keep up with a 19200 baud serial stream. > >Oh, jeez. You are too impressed with small potatoes. It should >be keeping up with 1000 19200 baud serial streams. Never dropping a character at 19200 is way beyond what Windows can do. Linux can do it so I can use Linux and get on with my work. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 16 Feb 2007 09:41
In article <er44is$p85$2(a)jasen.is-a-geek.org>, jasen <jasen(a)free.net.nz> wrote: >On 2007-02-16, Ken Smith <kensmith(a)green.rahul.net> wrote: >> In article <be273$45d50d69$49ecf9d$20196(a)DIALUPUSA.NET>, >> nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >> [.....] >>>None of the has anything to do with the OS biz. >> >> >> We just had another wonderful experience with XP. Characters pumped into >> the serial port may take up to 5 seconds before a DOS application running >> under XP gets to see them. Most of them eventually come through. >> >> Tomorrow, we may try it with "dosemu" to see how well that works. > >with the right serial driver it should work well, people were running serial >games in dosemu, dunno all the tricks they employed. I still haven't done it yet but thinking back over the other things I have done with "dosemu" and serial ports, this new program shouldn't be any trouble. It really doesn't need things to go much faster. If it responds to a chaacter within about 100mS it should be good enough. > >Bye. > Jasen -- -- kensmith(a)rahul.net forging knowledge |