Jihad needs scientists
in [Design]
|
From: krw on 11 Feb 2007 13:21 In article <npvss2ldhne7kdhh8bke7p72h7ehtuqeal(a)4ax.com>, MassiveProng(a)thebarattheendoftheuniverse.org says... > On Sat, 10 Feb 2007 17:35:06 -0500, krw <krw(a)att.bizzzz> Gave us: > > >You don't have a clue what you're talking about. THey had the > >source code, but no license to sell it. > > Not true. Typical clueless Dimbulb. > The source code is what never got delivered, dumbass. They DID have > the agreement to use it. Billy just never came across with the goods. The source to Win32 certainly was. > The only source they had was the win 3.11 code, at best. Clueless Dimbulb. > DesqViewX suffered the same defeat, but the difference is that they > never had an agreement with Billy to get full win32 compatability. > > IBM DID. And did have full Win32 compatibility, but couldn't keep up with the shifting sands. -- Keith
From: Phil Carmody on 11 Feb 2007 13:40 krw <krw(a)att.bizzzz> writes: > In article <87zm7k3a0l.fsf(a)nonospaz.fatphil.org>, > thefatphil_demunged(a)yahoo.co.uk says... > > Care to highlight the major architectural differences between the > > current FSL offerings in the 6800 family to the original processor? > > And on-die serial controllers et al. do not count as part of the > > processor architecture. > > A Core-2-duo will still execute 8088 binaries. My god, do you take not-answering-the-question lessons from BAH? Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: krw on 11 Feb 2007 13:52 In article <87vei835di.fsf(a)nonospaz.fatphil.org>, thefatphil_demunged(a)yahoo.co.uk says... > krw <krw(a)att.bizzzz> writes: > > In article <87zm7k3a0l.fsf(a)nonospaz.fatphil.org>, > > thefatphil_demunged(a)yahoo.co.uk says... > > > Care to highlight the major architectural differences between the > > > current FSL offerings in the 6800 family to the original processor? > > > And on-die serial controllers et al. do not count as part of the > > > processor architecture. > > > > A Core-2-duo will still execute 8088 binaries. > > My god, do you take not-answering-the-question lessons from BAH? Why don't you go play with your brother, the dumb donkey? You obviously can't make conversation with the adults. -- Keith
From: Ken Smith on 11 Feb 2007 15:47 In article <MPG.2039242827cf640a989f9b(a)news.individual.net>, krw <krw(a)att.bizzzz> wrote: >In article <eqnjc6$soo$1(a)blue.rahul.net>, kensmith(a)green.rahul.net >says... [....] >> >Nope. The '432 was announced well before the '286. I was at the >> >Intel unveiling (one of IBM's representatives) at the Grand Hyatt >> >in NYC. BTW, the 432 was three chips, not two. >> >> Did you actually see any chips that worked. At the time I was visited by >> the Intel folks, the 432 was not yet available and the 286 was already >> planned. This was late 1981 or early 1982. > >They claimed to have one working, sorta. We got a kit of >supposedly good chips later but I never had the motivation to do >anything with them. IIRC, the Grand Hyatt event was Oct '80. I never bothered to get the kit. We went x86. This was an embeddeed application BTW. > >> >It's most "interesting" aspect was the single-level store. Quite >> >like IBM's ill-fated FS and later AS400 (as I mentioned). >> >> I thought the most interesting was the protection against attempts to do >> inappropriate operations of variables. It doubled the number of memory >> operations needed so it cost hugely on perfromance. > >I _theory_ the '286 was supposed to do this on a segment basis. >Each process was supposed to have a separate segment. That doesn't come close to what the 432 was supposed to do. It kept track of the type of each variable each part of the code was allowed to get at. It would biff if you tied to do a floating point operation on an inteeger etc. >> >I suggest that you have no clue. 80868 is a 16bit machine. You >> >might want to try to count again. The PC market wasn't going to >> >"swing" anywhere, particularly to the 68K. Your argument is simply >> >silly. >> >> I said "the market" not the "PC market". > >the "market" outside the PC market is irrelevant to the x86. A >couple hundred million, hundred dollar (and up) chips a year is >rather an important market to hold onto. Enough that backwards >compatibility is essential. Intel almost screwed the pooch with >Itanic. I suggest you set the controls of the wayback machine to 1981 and look at the market them. Industrial folks were still important to Intel back then. >> I suggest you go back and reread >> what I wrote. It was correct. You simply missed the point because you >> were thinking PC. > >You are not correct in any way. The PC market *IS* the market for >x86, to the tune of Gigabuck$. Today. This is not the climate of the day of the x86's intruduction. >> No, I said it was the best on Intel introduced. I suggest again that you >> read more carefully. > >The 8051 is even more of a kludge than the x86, yet the best Intel >produced? Sheesh, you have a weird sense of "best". Hell, the >8085 had a more sane ISA than the 8051. I disagree about which is worse. The 8085 was an ok processor too but you will notice that it is mostly gone and the 51 is still here. The market seems to disagree with you. >> No, it used up a 16 bit register to supply only 4 more bits of addressing. >> It also required a trip through the ALU to do a memory access. This is >> part of why the 8086 was so darn slow. > >Wrong. All 32 bits were used. If only 4bits were used, the >minimum segment size would have been 64K. The trip through the ALU >was simply a microarchitectural corner-cut to eliminate another >ALU. It has nothing to do with the macroarchitecture or ISA. You could only address 20 bits worth of memory. The fact that it took the extra trip to the ALU is part of why the x86 is so stupid. >> No, an implementation of a stupid idea. > >No, an implementation detail caused by a lack of transistors. No, like I said a stupid idea. They could have used less transistors to have allowed 32 bit addressing much like the 8080 did. >> It means that you either had to >> run through the existing ALU or add one just to get to memory. This means >> that instead of using the ALU to do usefule stuff, you had to wait while >> it fiddled about. > >These sorts of tradeoffs are often taken to save transistors at a >small expense in performance (often the operations can be hidden). The x86 ended up taking a whole bunch of clock cycles to do things like a subroutine call because of the silly idea. >> >> The x86 had to keep the 8086 instruction >> >> set because Intel knew that they couldn't strand the code and expect to >> >> sell many processors. >> > >> >Wrong! They had the PC market and wanted to keep it. A radical >> >change would have put them in the dumper. See: Itanic. >> >> You just rephrased what I said after calling me wrong. > >Before you said that backwards compatibility wasn't the reason for >the x86 layers of crud. The 8086 was crud. I never said layers. They have had to keep the crud. It is a pile not a bunch of layers. [....] >Actually, when I was doing such things, I used AAD and AAM quite a >bit. There were neat tricks in there, but it's been 20 years since >I've done any significant x86 assembler. I did quite a lot of 8086 asm. I used the AAM exactly once that I can think of. I had to add 32 bit values many times. >> >Why would there be a 32b add in a 16b processor? That would >> >require a 32b ALU or microcode specifically for that one >> >instruction. Sheesh, what a silly argument! >> >> The 8080 could add 16 bit values. > >You don't like multiple pass ALUs, remember? No, I don't like silly needless passes through the ALU. There is a huge difference. [....] >Yes, I'm typing while on my back. > >> It makes many routines take extra instructions because they didn't have >> the ability to redirect the register used. > >That's rarely a problem to anyone who's programmed an x86 for more >than a month. One usually knows ahead of time what the variables >are going to be used for. I had been coding for quite some time when I really regretted that characteristic of the 8086. We actually ended up passing part of the task over to the 8089 and some special purpose harware because the 8086 simply couldn't be coded to get the job done fast enough. The extra register loads inside the loop reeally slows things down. That combined with having more values than registers and the stupid slow memory loads made it hopeless. > Register loading is a function of the >number of registers. With just a few registers you're going to be >doing it anyway. Puting the data in the right place the first time >isn't such a big deal. If two values must be in the same register, you have to move between registers. The operation of the rep and loop forces register loads to be inside the loop. This slows things down. > If you want to complain here it's not about >the lack of othogonality, rather the dearth of registers. >Remember, x86 is thirty years old. AX, BX, CX, DX, IS, IP, DS, ES Thats 8 16 bit registers. That isn't a serious shortage. The fact that you can't use the DS and ES as would make sense and that the memory operations were so slow made it so that you always felt short on registers. [....] >> I still disagree. The 8086 was much worse and for no good reason. > >There is very good reason; lack of transistors. Later version are >far more orthogonal. > >> The 8051 was a very limited machine to keep it simple. > >Why don't all arithmetic/logical instructions use the same >operands? Now there's dumb! Count up the op codes and notice there are none left. The important things got implemented. [...] >> There is only one opcode not used. If you wanted to add more >> instructions, you'd have to give up something. > >What's that got to do with the price of oats in China? If you want to have more instructions, you'd have to add more bits to the opcodes. On the whole they picked the right ones to implement. -- -- kensmith(a)rahul.net forging knowledge
From: Phil Carmody on 11 Feb 2007 16:49
krw <krw(a)att.bizzzz> writes: > In article <87vei835di.fsf(a)nonospaz.fatphil.org>, > thefatphil_demunged(a)yahoo.co.uk says... > > krw <krw(a)att.bizzzz> writes: > > > In article <87zm7k3a0l.fsf(a)nonospaz.fatphil.org>, > > > thefatphil_demunged(a)yahoo.co.uk says... > > > > Care to highlight the major architectural differences between the > > > > current FSL offerings in the 6800 family to the original processor? > > > > And on-die serial controllers et al. do not count as part of the > > > > processor architecture. > > > > > > A Core-2-duo will still execute 8088 binaries. > > > > My god, do you take not-answering-the-question lessons from BAH? > > Why don't you go play with your brother, the dumb donkey? You > obviously can't make conversation with the adults. The capabilities of the X register, you say? No that's the same since the original design. You were so close. If you'd have mentioned the Y register then you'd have picked up on something that's only been the same since 1979, rather than 1975. Or were you instead simply devoid of technical content? We can all see the answer to that latter question. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./. |