🚀 go-pugleaf

In article <4rsh38$77n@natasha.rmii.com> underwoe@rmii.com "Edmond" writes:

>Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>>In article <4rkkhn$54@natasha.rmii.com> underwoe@rmii.com "Edmond" writes:
>>
>>>Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>>>
>>>>Certainly, they are 32 bit applications even running under DOS (they use
>>>>32 bit DOS extenders). Only things like disk I/O have o use 16 bit code
>>>>and CPU speed isn't particularly relevat there since it is waiting for the
>>>>disk most of the time.
>>>>
>>>
>>>32-bit doesn't mean that you are using a flat memory model.
>>
>>In theory no. In practice with current OSs and extenders that is
>>exactly what is means.
>>
>
>I disagree.  

OK then give me an example of a system that doesn't execute 32 bit code
in a flat memory model.

>>> The latter is 
>>>just as important as using 32-bit registers for data.  Segmented memory 
>>>causes you to subvert the branch prediction model of the P-PRO which 
>>>causes all sorts of processor stalls apparently.  
>>
>>That and register aliasing are the main things that have given the Ppro a
>
>Register renaming hasn't done this for other processors.  

No doubt - either because the archetecture makes this a non-issue or the
processor has the silicon to work around the problem. As I understand it
the PPro's renaming can only reference a whole 32 bit register. This
means that, for example, if the code references AH and AL consecutively
the processor doesn't realise the operations are independent and can't
execute them in parallel. This sort of thing is much more likely to
happen in 16 bit than 32 bit code.

>>bad name for 16 bit apps. 32 bit code give you more flexibility in the
>>use of registers and until a 4GB address space ceases to be adequate
>>code can use a 'small' memory model.
>
>Segmented pointers are terrible for the PRO.  It kills the branch prediction 
>model.  32-bit code is probably less flexible (you can't chop registers in half >like mov 8,al etc.), but more predictable.  

The fact that you can't chop 32 bit registers in half is a win w.r.t. the
problem above. OTOH if you could the processor would probably have the
logic to deal with it efficiently.

In 16 bit code how often do branches actually change the segment value?

...

>Win95 thunks it's 32-bit API down to 16-bit.  You'll see slowdown no matter 
>what.  

AFAIK a good proportion of Win95 is written in 32 bit code. From what
I've been hearing recently, when you put a PPro in a decent motherboard
e.g. Natoma/440FX with EDO RAM its 16 bit performance isn't as bad as
people thought - not much worse than a similarly clocked Pentium. I've seen
a number of reports now of PPro 200's outstripping Pentium 166's under DOS.
I have little doubt that they would beat Pentium 200's under Windows 95.

One of the big problems with early PPro motherboards/chipsets was terrible
PCI bus performance (less than 10MB/sec) due to chipset bugs. This
naturally produced a poor graphics speed and hence poor Win95 performance.
Natoma can equal or beat the best Pentium PCI chipsets (80-90MB/sec)

Also don't forget that the PPro has better caching.

>>Under DOS I would expect it to deal with VGA modes directly, with
>>possibly some 16 bit calls for VESA modes.
>>
>
>Doesn't matter.  If the data that your using is 16-bit segmented, then you'll 
>get a slow down.  

What data are you talking about?

>>> WinNT 4.0 would give you much superior 
>>>graphics performance under the PRO.  
>>
>>I doubt whether the difference would be noticable, possibly not even
>>measurable except, as stated above, where it is able to take better
>>advantage of the graphics/sound card features.
>
>Since I have both Win95 and NT 4.0b2 on my system, I have very few doubts.

We may be talking at cross-purposes. I've been arguing along the lines of,
say, direct accessed the screen in, a 32 bit DOS extended environment
(e.g. a 32 bit game) vs NT code. I don't know enough about the windowing
code in Win95 specifically to compare those two front ends. If the
Win95 front-end is 16 bit then NT should be faster on a Pentium or
even a 486, let alone a PPro.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------