OSDev.org

Benk wrote:MMU and branch prediction will start to dissapear after 10 yeas to be replaced with 35% higher core counts and more advanced software MM ( which use Virtual addresses and patches the code when needed) .

Well, I don't get that one. MMUs implement virtual addresses, too, and code patching can't be safely done on binary code. (For machine code, there's no difference between a pointer and data, so how do you know where are the memory addresses in the code in order to change them ?)

Benk: Could you post links to some paper(s) discussing this? I'd like to read about this.

Neolander wrote:

Benk wrote:MMU and branch prediction will start to dissapear after 10 yeas to be replaced with 35% higher core counts and more advanced software MM ( which use Virtual addresses and patches the code when needed) .

Well, I don't get that one. MMUs implement virtual addresses, too, and code patching can't be safely done on binary code. (For machine code, there's no difference between a pointer and data, so how do you know where are the memory addresses in the code in order to change them ?)

You must be young ... IBM 360 employed code patching and many since there hasnt always been an MMU , DOS didnt use one most small CPUs dont from 8086 to Arm to Motorola. Binary code can be patched because you attach a map file of addresses ( or store it in the file headder) that allows you to tell what needs to be patched. uClinux has ElfPIC , Flat and FlatShared . PIC ( position independent code) code can be placed in any locations , Flat can be patched , Flat shared is patched with a lookup table.

fronty wrote:Benk: Could you post links to some paper(s) discussing this? I'd like to read about this.

It needs a lot of work still but

http://research.microsoft.com/apps/pubs/?id=69431
Disabling MM and relying on compiler patching and no run time checks results in a 11% perf improvement on a web server. (x86)

http://opensrc.sec.samsung.com/document ... 4_sait.pdf
http://opensrc.sec.samsung.com/document.html
uClinux showing IPC Context switches complete in 20us instead of 100us you can see the attraction for high core counts and Async IPC. (Arm)

Anyway this is a LONG term prediction , I think we will first see massive multi core Asyc , micro kernel OS ( which may use mmu or software protection) and these will blow away traditional OS on high core counts which wll lead to the MMU being redundant ( allong with a lot of research in terms of the practicalities of VM in software) .

My prevision is that in 20 years, we are going to see a 128bits processor.

Nathan wrote:My prevision is that in 20 years, we are going to see a 128bits processor.

Wikipedia says there was one in April 1997 http://en.wikipedia.org/wiki/Comparison ... re-GeForce

This is why I don't trust on Wikipedia for hardware things(Use the OSDev one).

TylerAnon wrote:

Nathan wrote:My prevision is that in 20 years, we are going to see a 128bits processor.

Wikipedia says there was one in April 1997 http://en.wikipedia.org/wiki/Comparison ... re-GeForce

Nathan wrote:This is why I don't trust on Wikipedia for hardware things(Use the OSDev one).

Well, no comment. Instead of reacting like anyone else would do at the sight of this, I will simply say: that page is named "Comparison of Nvidia graphics processing units".

Oh, I didn't saw that!

Wkipedia is not that bad .

From memory ..

8086 was 8 bit data , 16 bit address , 16 bit registers = was called a 16 bit CPU ( called 8 bit by 286 marketers)
80286 16 bit data , 20 bit address ( 24 bit via A20 keyboard pin) , 16 bit registers = 16bit CPU
80386 32 bit data , address & Registers
80486 as 386 + 80 bit floating point.
Pentium MMX as 386 + 64 bit integer SSE reg mapped onto 80 bit floating point reg
Pentium 4 SSE2 as MMX + SSE2 , 64 bit integers instructions , seperate 80 bit FP.
x64 64 bit data , 40-48 bit addressing ( board dependent) , 64 bit registers , 128bit XMM registers.

So the integer register size or data is really the best indicator though somewhere allong the line marketing people associated it with Address space.

I would argue that x86_64 is a 128 bit CPU but not a pure one since you can do common operations on the 128 bit XMM registers including mov ( via movdqa) but not all.

While they could have implemented "pure " 128 bit it was pointless since apps worked mainly on 32 bit. Though they did allow you to work on 4 32 bit instructions at once as this is common. Even today its not common for apps to need 64 bit ints or 64 bit addressing.

Benk wrote:I would argue that x86_64 is a 128 bit CPU but not a pure one since you can do common operations on the 128 bit XMM registers including mov ( via movdqa) but not all.

Whaaaa...?! That makes SSE a 128-bit ISA, not x86_64.

If Intel and AMD call x86_64 a 64-bit ISA, then it's a 64-bit ISA by virtue of them calling it that. Aside from that, the main registers are also 64 bits wide.

Nathan wrote:My prevision is that in 20 years, we are going to see a 128bits processor.

A general purpose 128-bit processor (..data/address) is possible, but.. can you even fathom how large of address space 64-bit is? let alone 128-bit?

Let's put it this way:
2^16 = 65536 (64K), GP register size on <= 286, and in realmode.
2^20 = 1048576 (1M), 20-bit address bus on the original 8086 allowed accessing 1MB of physical memory using segmentation tricks.
2^24 = 16777216 (16M), 286 featured a 24-bit address bus, early protected mode, and a MMU.
2^32 = 4294967296 (4G), 386 bumped address and data bus sizes to 32-bit.
2^36 = 68719476736 (64GB), Pro/PIII introduced PAE/PSE36 at different times.. larger address bus but limited by a 32-bit data bus, needs paging tricks, process addressing limited to 4G but can be located in higher physical memory.
2^48 = 281474976710656 (262,144GB), AMD64 architecture, long mode, 64-bit data bus with a variable address bus, 48-bit today.. virtual addresses appear 64-bit but contain non-touchable bits.
2^52 = 4503599627370496 (4,194,304GB), future extension for AMD64.
2^64 = 18446744073709551616(17,179,869,184GB or 16,777,216TB), ditto.
2^128 = 340282366920938463463374607431768211456(..you do the math).

Why would we ever transition to a 128-bit general-purpose processor? perhaps a processor with a 128-bit data bus.. but.. I just don't see why, SSE and friends exist for fancy math and whatnot.

The future of processors? they'll probably get a few more cores.. and then more useless stuff will be moved onto the processor die, maybe a sound processor, why not? you're paying for it.

Hmm, I still prefer my good and old ARM.

JackScott wrote:

Benk wrote:I would argue that x86_64 is a 128 bit CPU but not a pure one since you can do common operations on the 128 bit XMM registers including mov ( via movdqa) but not all.

Whaaaa...?! That makes SSE a 128-bit ISA, not x86_64.

If Intel and AMD call x86_64 a 64-bit ISA, then it's a 64-bit ISA by virtue of them calling it that. Aside from that, the main registers are also 64 bits wide.

A significant proportion of optomised code now uses the 128 bit XMM registers its surprising how much.

Intel & Amd MARKETING people call it 64 bit to distinguish it from 32 bit. They also called the 8086 16 bit untill the 286 came out after which the marketing department called the 8086 8 bit.

Brynet-Inc wrote:

Nathan wrote:My prevision is that in 20 years, we are going to see a 128bits processor. =P A general purpose 128-bit processor (..data/address) is possible, but.. can you even fathom how large of address space 64-bit is? let alone 128-bit?

~

isnt 2 ^72 the number of atoms in the universe....