Prev: CFP: Informatics 2010: new date - until 15 March 2010
Next: Call for papers: HPCS-10, USA, July 2010
From: Terje Mathisen "terje.mathisen at on 11 Mar 2010 13:15
Stephen Fuld wrote:
> I view the near ubiquitous inclusion of caches as not a "new invention"
> that wasn't obvious at the time, but a good reaction to changing
> technology of processors getting faster more quickly than memories
> getting faster.
>
> Similarly, going to say a 32 bit wide interface on an 8086 would be a
> waste of money. More pins, and the requirement for more memory chips in
> return for essentially no performance gain. It was a good engineering
> trade off analysis, not lack of knowledge that drove the decision.

Without a proper code cache, instruction fetch will dominate the bus
traffic, so having a 32-bit interface for ifetch would definitely help
since most instructions could be retrieved in a single cycle.

The 8086 model did have a 16-bit bus as well as an 8-byte instruction
buffer, which meant that at least during those instructions that didn't
load or store anything, the bus could be used to load one or two
upcoming opcodes.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: Tim McCaffrey on 11 Mar 2010 14:36
In article <4B99084B.3070601(a)patten-glew.net>, ag-news(a)patten-glew.net says...
>

>
>E.g. evaluate an 8086 with modern parameters. Or a i486, if that's what you
care about.
>
>Take the 8086. If I remember correctly, circa 1 instruction, 1 data memory
reference per
>instruction. No cache.
>Didn't matter much when memory was one cycle away, but now memory is circa
100 cycles away.
>
Well, I think the average was something like 2.3 bytes per instruction, and
the memory was 4 cycles to access.

For the most part, when you were trying to get a feel for execution time on
the 8088 you just counted the number of bytes in the instruction and the
number of bytes it read/wrote to memory, multiplied the total by 4 and it was
very close to the time it actually took (much closer than what the data book
implied).

Of course, with a modern process, you could put all 1 Megabyte of very fast
memory right on the chip. There are no TLBs or cache look up structures to
slow things down. I don't know if that would scale with the speed of the
processor or not.

- Tim

-

From: Paul Wallich on 12 Mar 2010 15:39
Terje Mathisen wrote:
> Andy "Krazy" Glew wrote:
>> I think that it would be more practical to take the old design and
>> simulate it a new design library.
>>
>> E.g. evaluate an 8086 with modern parameters. Or a i486, if that's what
>> you care about.
[...]

> The original IBM PC and clones all ran at 4.77 MHz, but dram refresh
> stole a few percent of available bandwidth, so for most practical
> considerations you could guess that your code would take 1 us per byte.
>
> It was only when you used the few _really_ slow instructions like DIV
> (and MUL) that the 6-byte opcode prefetch buffer would have time to fill
> up.
>
> If you implement the exact same process today, without adding any caches
> or increasing the bus width, the cpu would be about an order of
> magnitude faster, still limited by the speed of dram.

Except that the entire address space of those chips could fit in the
same die with the processor. The CPU would need to be running about
2000x the original speed to keep up with EDRAM.
From: Stephen Fuld on 13 Mar 2010 21:48
On 3/11/2010 10:15 AM, Terje Mathisen wrote:
> Stephen Fuld wrote:
>> I view the near ubiquitous inclusion of caches as not a "new invention"
>> that wasn't obvious at the time, but a good reaction to changing
>> technology of processors getting faster more quickly than memories
>> getting faster.
>>
>> Similarly, going to say a 32 bit wide interface on an 8086 would be a
>> waste of money. More pins, and the requirement for more memory chips in
>> return for essentially no performance gain. It was a good engineering
>> trade off analysis, not lack of knowledge that drove the decision.
>
> Without a proper code cache, instruction fetch will dominate the bus
> traffic, so having a 32-bit interface for ifetch would definitely help
> since most instructions could be retrieved in a single cycle.

Yes, but even Intel recognized that people weren't willing to pay for a
wider bus. IBM even bought the 8088 which was the same processor as the
8086 but with an *8-bit* bus for their first PC. The reason they gave
was that system cost would have been too high with a 15 bit bus. My
point is not that there weren't things that could have been done to
improve performance, but the decisions the engineers made were not out
of ignorance of these things, but as a correct response to the
technology of the day.


> The 8086 model did have a 16-bit bus as well as an 8-byte instruction
> buffer, which meant that at least during those instructions that didn't
> load or store anything, the bus could be used to load one or two
> upcoming opcodes.

Yes, and IIRC, the 8088 has a slightly larger instruction buffer as a
counter to the smaller bus width. Again, an intelligent response to
what was available and needed.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)
From: Tim McCaffrey on 13 Mar 2010 23:37
In article <hnhiqf$gap$1(a)news.eternal-september.org>,
SFuld(a)alumni.cmu.edu.invalid says...
>
>On 3/11/2010 10:15 AM, Terje Mathisen wrote:
>> Stephen Fuld wrote:
>>> I view the near ubiquitous inclusion of caches as not a "new invention"
>>> that wasn't obvious at the time, but a good reaction to changing
>>> technology of processors getting faster more quickly than memories
>>> getting faster.
>>>
>>> Similarly, going to say a 32 bit wide interface on an 8086 would be a
>>> waste of money. More pins, and the requirement for more memory chips in
>>> return for essentially no performance gain. It was a good engineering
>>> trade off analysis, not lack of knowledge that drove the decision.
>>
>> Without a proper code cache, instruction fetch will dominate the bus
>> traffic, so having a 32-bit interface for ifetch would definitely help
>> since most instructions could be retrieved in a single cycle.
>
>Yes, but even Intel recognized that people weren't willing to pay for a
>wider bus. IBM even bought the 8088 which was the same processor as the
>8086 but with an *8-bit* bus for their first PC. The reason they gave
>was that system cost would have been too high with a 15 bit bus. My
>point is not that there weren't things that could have been done to
>improve performance, but the decisions the engineers made were not out
>of ignorance of these things, but as a correct response to the
>technology of the day.
>
>
>> The 8086 model did have a 16-bit bus as well as an 8-byte instruction
>> buffer, which meant that at least during those instructions that didn't
>> load or store anything, the bus could be used to load one or two
>> upcoming opcodes.
>
>Yes, and IIRC, the 8088 has a slightly larger instruction buffer as a
>counter to the smaller bus width. Again, an intelligent response to
>what was available and needed.
>

Actually, I think the 8088's was 4 bytes, and the 8086 was 6.

- Tim

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CFP: Informatics 2010: new date - until 15 March 2010
Next: Call for papers: HPCS-10, USA, July 2010