Bloatware AmigaOS?

[Hammer]

HenryCase wrote:

stefcep2 wrote:
Thats an issue related to the fact that the hardware x86 design is dictated by the OS that will run on it, not the other way around.

In what way is an x86 processor limited by the OSs that run on it? Windows could be ported to any processor architecture and still look and feel the same it does on x86, provided the processor was fast enough to run it. Similarly, any OS could be ported to x86.

Waccoon wrote:
I disagree. Even X86 is pretty efficient if you think about it, because hardware engineers cannot be anywhere near as sloppy as software engineers

One of the main factors that prevents x86 being efficient is the legacy of previous chip designs. One example of x86 legacy is the A20 line gate. See here:
http://en.wikipedia.org/wiki/A20_line

This is not applicable for EFI enabled Mactels, some Gateway MCEs, some Xeon servers boards unless you want to boot non-EFI enabled boot loaders (via EFI's Compatibility Support Module (CSM)). Early IA-32 Mactels doesn't have CSM.

In post-1997 PCs, modern IBM PC and compatibles do not have separate chips physically on-board (keyboard controller, interrupt controller and etc); they actually have one chip which emulates all these IBM PC and compatible chips called the Super I/O chip. The Super I/O chip emulates A20 line and 'Fast A20 gate' options.

A20 gate issue doesn’t affect computation performance once X86 enters Protected Mode.

[Hammer]

stefcep2 wrote:
Iif there's one thing I have learned over the years is that software will always grow to fill the hardware.  Amiga hardware has been caught in a 1993 time-warp, so the OS and software run within these hardware constraints.  It gets interesting if you emulate some of the different Amiga OS distributions out there:  Amikit looks like the most modern AmigaOs you can get in terms of eye candy and "features" but it is far slower than Amigasys or classic amiga, which aren't as "feature" rich.  Still, the Amiga would have bloated over time, but not nearly as much as X86.  Don't forget the X86 hardware platform is basically designed to suit the windows way of doing things ie its windows that demands the hardware be designed to suit it, not that windows is made to run on the hardware.

The development platform for 64bit Windows 2000 was DEC’s Alpha. This code base forms the basis for IA-64 and AMD64 (Codename: Anvil) Windows XP (NT5.2) and 2K3 (NT5.2) editions. NT5.2 codebase serves as basis for second Windows Vista development refresh i.e. early Windows Vista development builds was based from NT5.1 (Windows XP 32bit edition).

Actually, PowerPC’s little endian mode was designed with Windows NT in mind. This mode was dropped in PowerPC 970. For Xbox 360 development, Microsoft has Windows NT5.x based kernels and modifed DirectX9 stack running on Apple's PowerMac G5s and it doesn’t require PowerPC's little endian modes.

XBOX360 carries a superset of DirectX9 stack and it's Xenon CPU include instructions for Direct3D.

Win32 layers is portable enough for running on MIPS, Alpha, ARM, PowerPC and 'etc'. Windows CE (with desktop) on ARM/MIPS based device "look and feels" like Windows 9x/NT4 btw.

http://the-gadgeteer.com/review/moreio_ezpad_ce_net_device_review

 Much of the efficiency that comes from the Amiga is because the hardware and os are tightly integrated together.  But you can't get that with generic mass produced hardware,

Factor in AROS X86.

it has to be propriatory and no users  want that because its expensive eg remember the powerpc macs cost nearly twice as much as equivalent PC hardware at the time.

Windows NT runs fine on MIPS and Alphas. Remember Newtek’s Lightwave accelerators workstations such as Raptors in CUAmiga/ Amiga Format magazines?
 

[Hammer]

HenryCase wrote:

stefcep2 wrote:
Thats an issue related to the fact that the hardware x86 design is dictated by the OS that will run on it, not the other way around.

In what way is an x86 processor limited by the OSs that run on it? Windows could be ported to any processor architecture and still look and feel the same it does on x86, provided the processor was fast enough to run it. Similarly, any OS could be ported to x86.

Waccoon wrote:
I disagree. Even X86 is pretty efficient if you think about it, because hardware engineers cannot be anywhere near as sloppy as software engineers

One of the main factors that prevents x86 being efficient is the legacy of previous chip designs. One example of x86 legacy is the A20 line gate. See here:
http://en.wikipedia.org/wiki/A20_line

For Pentium(P5) and greater, the P5 processor has a FAST A20 option that bypasses the A20 line completely. To set the A20 line, there is no need for delay loops or polling i.e. you only need 3 simple asm instructions.

in al, 0x92
or al, 2
out 0x92, al

FAST A20 capability must be detected or something else can happen. Bootloader such as Grub can enable A20 gate.  

[Hammer]

Roj wrote:
The mouse driver distribution for my Logitech cordless is just over 60 megabytes. That's just a mouse driver. I think it's the other way round. From that, it looks like Windows lacks the resources and needs special help to get a mouse to have proper behavior.

For basic mouse functions, Windows XP and Vista doesn’t need Logitech’s setpoint software.

Logitech’s Setpoint 4 software includes photos for different Logitech’s mices.

[Hammer]

stefcep2 wrote:

In what way is an x86 processor limited by the OSs that run on it? Windows could be ported to any processor architecture and still look and feel the same it does on x86, provided the processor was fast enough to run it. Similarly, any OS could be ported to x86.

I do not know enough details about x86 **processors**, i was talking to the whole PC architectural design which nowdays is x86 based for home use.

AMD's EV6 bus architecture (for K7 Athlon) was based on DEC's Alpha EV6 i.e. "big-tin" or workstation platform.

There are K7 Athlon (slot versions) motherboards that supports both Alphas and K7 Athlons. With AMD’s X86 motherboard partners, AMD managed to make an EV6 based motherboard cheaper.

AMD's HyperTransport (for K8/K10) is based on Alpha EV7’s bus architecture.    

(Nevertheless per clock cycle its my understanding that the x86 processors did less than 68k.).

Motorola 68060 IPC would be blown away by AMD K7/K8 and Intel Pentium III/Pentium M/Core/Core 2.

Motorola 68060 is not same league as DEC’s Alpha in running Lightwave.

In basic terms, AMD K7/K8/K10 Athlon and Intel Pentium III/Pentium M/Core can issue and retire 3 X86 instructions per cycle. Intel Core 2 Duo can can issue and retire 4 X86 instructions per cycle.

68060 can only issue two instruction (one integer and one float) per cycle or 2 integer instructions and one branch instruction per clock cycle.

AMD K7 3-way issue instruction can be a mix of float or integer e.g. 3 integer, 3 floats, 2 integer + 1 float, 1 integer + 2 floats,  

X86 is just an ISA and modern X86 processors (Intel Pentium Pro, AMD K5) translates (emulates) these CISC (variable length) instruction to RISC like instructions (e.g. fix length instructions) over multiple-pipelines (i.e. 6 wide for K7 Athlon).  

[Hammer]

I would just like to say that I mentioned the A20 line as an example x86 legacy, but I dont know all the details of legacy support for older software. Do you know of any other examples?

Stacked model X87 FPU and FXCH instruction. Both which was fixed(workaround) in AMD's K7 Athlon i.e. hardwired FXCH (effective latency of 0-cycles), hardware translator for FPU stack model to register FPU model.

X87's lack of fused FADD and FMUL instructions i.e. Intel Core 2's fixes this issue by detecting (hardware) dependant FADD and FMUL instructions and fuse the together.

Stack FPU model was dumped in AMD64/Intel64/X64 modes.

[Hammer]

Or is the some architectural reason that would have limited it from the same type of improvements that make the x86 still viable?

RISC hype...

What were the abilities of the 1993 Pentium or 1995 Pentium Pro in regards to clock cycles?

Like the other P6 class cores(e.g. Pentium II, Pentium III, Pentium M, Core1), Pentium Pro has three x86 decoders i.e. 3 X86 instructions per cycle.

Pentium Classic can issue two X86 instructions per cycle (with limitation).

The P6 has partially pipelined FPU (for instruction multiplies). Like Pentium Classic's FPU, 68060's FPU is not piplined.

K7 Athlon has a fully superpipelined FPU.

[Hammer]

HenryCase wrote:

downix wrote:
No, '95-'96 would have been post-AAA, Hombre chipset.  AAA was to be 3.0, but CBM put it's development on pause, instead releasing the interim AGA.  When they restarted AAA development, they soon found themselves too far behind the curve, so they began Hombre, slated for release in '95.

Thanks for this info.

Just out of interest, if AAA had been released instead of AGA (i.e. at the same time) how would it have compared, tech specs wise, with IBM-PC compatible and Apple graphics h/w?

About on par with ATI's Mach 32.
http://en.wikipedia.org/wiki/ATI_Mach

Factor in Intel has 860/960 RISC 3D hybrid chip...

[Hammer]

persia wrote:
So what about modern PCs and Macs which all use multi-cores, how do they compare with the old style P4s?

This is a large topic.
http://arstechnica.com/articles/paedia/cpu/core.ars
http://arstechnica.com/articles/paedia/cpu/core.ars/4
http://arstechnica.com/articles/paedia/cpu/core.ars/5

This refers to Intel's Core 2 Duo/Quads.

PowerPC G4's Altivec implementation was good, but it was throttled by a crap bus and chipsets. If G4 used EV6 bus; the outcome would have been different. Both AMD and Intel have 128bit FP hardware units with plenty of bus bandwidth.

[Hammer]

Fully agreed. While, sure, modern day GPU's are more than adequate, truth is, the rest of a PC or Mac's chipset is downright anemic for performance. I build these things every day, and deal with these limitations. Example, the common AC97 sound system that's universal nowadays.

As for AC97 or HDA, Lintel/Wintel/Mactel's chipsets are designed with a modern X86/X64 processor in mind.

[Hammer]

There are more chips out there than PPC and x86. ARM, MIPS, SuperH, and SPARC are all still viable, and each has their own unique strengths that lend themselves to a desktop platform, such as more efficiency, better OP-per-clock ratio, and... they're LICENSEABLE.

Let's see SPARC IV competes against Celeron/Pentium Dual Core (Core 2 based), K8 Sempr0n and Athlon 64s in the race to bottom(for price).

[Hammer]

downix wrote:

Hammer wrote:

persia wrote:
So what about modern PCs and Macs which all use multi-cores, how do they compare with the old style P4s?

This is a large topic.
http://arstechnica.com/articles/paedia/cpu/core.ars
http://arstechnica.com/articles/paedia/cpu/core.ars/4
http://arstechnica.com/articles/paedia/cpu/core.ars/5

This refers to Intel's Core 2 Duo/Quads.

PowerPC G4's Altivec implementation was good, but it was throttled by a crap bus and chipsets. If G4 used EV6 bus; the outcome would have been different. Both AMD and Intel have 128bit FP hardware units with plenty of bus bandwidth.

Fully agreed, hence why I'm currently modifying the SPARC T1 to use a Hypertransport bus rather than it's current proprietory bus design.  Cuts costs, *and* booses speed.
.

Officially, Sun Microsystems is currently evaluating AMD's Torrenza for all Sun platforms.  

http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~112780,00.html