Jihad needs scientists
in [Design]
|
From: jmfbahciv on 18 Feb 2007 07:53 In article <e1get2tmfd5mvpdu7b5u79b80seuhcas6h(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Sat, 17 Feb 07 12:29:49 GMT, jmfbahciv(a)aol.com Gave us: > >>In article <er4gcr$1ln$6(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>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. >>> >>>If you call two tasks "multi", >> >>I don't :-). >> >>> I wrote one that worked quite nicely. It >>>allowed the user interface task to run while disk I/O and printing etc >>>also ran. It was very special purposed so it wouldn't be something to >>>market. >>> >>>It really isn't that hard to create a multitasking system if only one task >>>is allowed to touch a given bit of hardware. Mostly you just have to >>>change the stack pointer and return from the timer interrupt into the >>>other task's context. >> >>You have a very big IF in that sentence. ;-) > > As if you would even know. As it happens, I do know. /BAH
From: jmfbahciv on 18 Feb 2007 07:55 In article <er91e0$ji1$1(a)jasen.is-a-geek.org>, jasen <jasen(a)free.net.nz> wrote: >On 2007-02-16, jmfbahciv(a)aol.com <jmfbahciv(a)aol.com> wrote: >> 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. > >means you have to make room on the stack (where BP offsets >are typically used) for the counter. Now think. You either have to use software to check out of range or have hardware that will cough at you when you do go out of range. We were fortuante in having hardware spit at you if you did flagrant things. /BAH
From: nonsense on 18 Feb 2007 08:29 jmfbahciv(a)aol.com wrote: > In article <er7blr$ijh$4(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: > >>In article <er6sft$8ss_009(a)s994.apx1.sbo.ma.dialup.rcn.com>, >><jmfbahciv(a)aol.com> wrote: >> >>>In article <er4gcr$1ln$6(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>> >>>>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. >>>> >>>>If you call two tasks "multi", >>> >>>I don't :-). >> >>I could do 3 too. >> >>It just takes a little more coding. > > > My point is that it should not take more coding to add and/or > subtract. To have to do coding in order to add one is a crock. > None of our old customers would have accepted this. We certainly > did not have the resources to code every time we needed to run > an extra task. > > >>>>I wrote one that worked quite nicely. It >>>>allowed the user interface task to run while disk I/O and printing etc >>>>also ran. It was very special purposed so it wouldn't be something to >>>>market. >>>> >>>>It really isn't that hard to create a multitasking system if only one task >>>>is allowed to touch a given bit of hardware. Mostly you just have to >>>>change the stack pointer and return from the timer interrupt into the >>>>other task's context. >>> >>>You have a very big IF in that sentence. ;-) >> >>Yes, but the two tasker served its purpose quite nicely. I created only >>the tool I needed for the purpose not a general OS. > > > Sure. I understand what you did. :-) Now think about all the > different kinds of hardware, formats, software, etc. and the > fact that each person's individual system are all different from > any other system in the world, past and future. > > You can't force everybody to code every time they want to do > something extra. Where's that supposed bright line between coding and using?
From: jmfbahciv on 18 Feb 2007 09:00 In article <9b5c0$45d854a8$4fe75aa$9801(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >jmfbahciv(a)aol.com wrote: > >> In article <er7blr$ijh$4(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >> >>>In article <er6sft$8ss_009(a)s994.apx1.sbo.ma.dialup.rcn.com>, >>><jmfbahciv(a)aol.com> wrote: >>> >>>>In article <er4gcr$1ln$6(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>> >>>>>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. >>>>> >>>>>If you call two tasks "multi", >>>> >>>>I don't :-). >>> >>>I could do 3 too. >>> >>>It just takes a little more coding. >> >> >> My point is that it should not take more coding to add and/or >> subtract. To have to do coding in order to add one is a crock. >> None of our old customers would have accepted this. We certainly >> did not have the resources to code every time we needed to run >> an extra task. >> >> >>>>>I wrote one that worked quite nicely. It >>>>>allowed the user interface task to run while disk I/O and printing etc >>>>>also ran. It was very special purposed so it wouldn't be something to >>>>>market. >>>>> >>>>>It really isn't that hard to create a multitasking system if only one task >>>>>is allowed to touch a given bit of hardware. Mostly you just have to >>>>>change the stack pointer and return from the timer interrupt into the >>>>>other task's context. >>>> >>>>You have a very big IF in that sentence. ;-) >>> >>>Yes, but the two tasker served its purpose quite nicely. I created only >>>the tool I needed for the purpose not a general OS. >> >> >> Sure. I understand what you did. :-) Now think about all the >> different kinds of hardware, formats, software, etc. and the >> fact that each person's individual system are all different from >> any other system in the world, past and future. >> >> You can't force everybody to code every time they want to do >> something extra. > >Where's that supposed bright line between coding and using? <GRIN> Believe it or not, compilation. I guess I'd better define this one. Compilation is the computing service that changes your ASCII character directions into data blocks that a linker can use to produce an executable set of machine insructions. /BAH
From: jasen on 18 Feb 2007 04:01
On 2007-02-17, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: > On Sat, 17 Feb 07 12:13:32 GMT, jmfbahciv(a)aol.com Gave us: > >>In article <aaict21nu9t1faaiodh912qu7en2240379(a)4ax.com>, >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>On Fri, 16 Feb 07 12:25:03 GMT, jmfbahciv(a)aol.com Gave us: >>> >>>> Other >>>>than instrumentation, there usually isn't any computing task that >>>>has to have the CPU pay attention to it *right now*. >>> >>> >>> A/V stream decoding does. Hell, even MP3 stream decoding does. >>> >>> When I watch Lost episodes on ABC.com, those streams get a LOT of >>>CPU time slices simply because the stream MUST be processed >>>continually. >> >>Son, it is time you learned about buffered mode I/O. >> > > You're an idiot. It doesn't stream directly to the video card. It > has to be processed first. The discussion isn't about how the stream > may or may not be being buffered, dipshit. It was about CPU time > slice priorities. with xmms, gtv, mplayer and vlc I'm seeing video frames in screen captures. it never used to do that, I used to just get a blue rectangle, and if I overlaid the same colour blue in another window it'd show through to the video. that may have been on different hardware. Bye. Jasen |