|
|
Subscribe / Log in / New account

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 5, 2014 23:38 UTC (Sat) by khim (subscriber, #9252)
In reply to: The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper) by roblucid
Parent article: The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Yes, it's similiar for compatability reasons to i386.. but it is different, IA32 was 32bits.

Sure. But 80286 and 8086 were 16bit while 80386 was 32bit so why 80386 is considered an x86 and Opteron is suddenly not an x86?

If switch from 16bit CPU to 32bit CPU is not considered a new architecture then switch from 32bit CPU to 64bit CPU should not treated as such. Or else we'll be forced to treat Pentium!!! with it's new SSE a new architecture which makes no sense whatsoever since it's basically a minor alteration of Pentium II. Heck, AVX-512 doubled number of SIMD registers and made them larger as well—yet it's still considered an x86, not something new!

Now we are on 64bit AMD, with a whole load more registers,

Wow. What an achievent. Sorry, but it's very similar to the introduction of SIB byte in 80386. Which instead of two base registers (BX and BP) and two index registers (SI and DI) gave us eight (with some limitations for ESP). This was quite nice change, but of course it was not a new architecture.

end of and your comments about Pentium4 seem to involve re-writing history, as it was the Opteron which introduced x86-64.
Sure, Operon (not Athlong64, my bad) introduced x86-64 architecture, I never said otherwise. But significant difference between -march=i386 to -march=x86-64 is the use of FPU in -march=i386 mode and SSE2 in -march=x86-64 mode. SSE2 registers and the appropriate instructions were introduced in Pentium4, not in Opteron.

Thus yes, AMD introduced valuable extension for the x86 architecture, obviously, no one says it's not true. But to say that it introduced the whole new architecture… nope, didn't happen. It's still good old x86—both internally and externally.


to post comments

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 6:31 UTC (Sun) by roblucid (guest, #48964) [Link] (6 responses)

If you look at the examples you give from point of view of what style assembly instructions a compiler generates, you'll see similarities.

If you look at things from point of view of memory model, what C source code compiles and runs, you'll see differences.

The modern x86-64, 64bit ABI is down to AMD it's NOT Intel's idea and no amount of hair splitting changes that.

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 9:50 UTC (Sun) by khim (subscriber, #9252) [Link] (5 responses)

The modern x86-64 is a minor tweak on top of the existing Intel-produced architecture. No amount of handwaving will change that fact.

The claim that AMD “invented” “new” x86-64 architecture is as ridiculous as claim that Benigno Castiglione built Duomo di Milano at the end of last century. Sure, he did some work on it, but his additions were relatively minor and not really all that significant. All the important decisions were made centuries before. Even more ridiculous look the claim that x86-64 superceded an x86: it's continuation of the very same thing! How could one supercede itself? The fact that for once AMD invented something which Intel also adopted (it tried many times: 3DNow!, XOP and so on, but was ignored both by Intel and programmers for the most part) is commendable, but it does not suddenly make an x86-64 a new architecture which could superceded x86. It's still the same old Duomo di Milano x86, just with some modern tweaks.

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 10:26 UTC (Sun) by PaXTeam (guest, #24616) [Link] (2 responses)

> The modern x86-64 is a minor tweak on top of the existing Intel-produced architecture. No amount of handwaving will change that fact.

heh, 'minot tweak' (do you have any clue about amd64?) and handwaving. amd64 is a new arch, no question about it, even according to intel, just read the titles of their own manuals: http://www.intel.com/content/www/us/en/processors/archite....

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 12:35 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

Even according to intel, just read the titles of their own manuals: http://www.intel.com/content/www/us/en/processors/archite....

So now we treat marketing BS as a gospel of truth? Come on. That's just stupid.

Do you have any clue about amd64?

Do you? I know that people who actually work with said architecture treat it as a single one (with significant tweaks here and there, sure). Both GCC and Linux kernel developers put files for x86 and x86-64 into a single subdirectory of their arch directory for a reason. Note that Linux developers initially treated it as two different architectures, but it made no sense and they were eventually merged. Yes, it's quite significant extension, but so is Sparc64 or 32bit and 64bit versions of POWER architecture.

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 15:20 UTC (Sun) by PaXTeam (guest, #24616) [Link]

it's called 'developer manual', not 'marketing BS' but then it's not the first time you've had reading comprehension problems, is it ;).

the directory structure of a source code tree has no bearing on what is a separate architecture (e.g., the BSDs have kept i386/amd64 separate). if anything, it reflects on some wise engineerig design decisions of AMD that kept the two archs close enough that some linux devs managed to drive through the x86 'unification'. as for how successful the x86 merge is:

$ find linux-3.15.3/arch/x86/ | wc -l
1255
$ grep -rwn CONFIG_X86_32 linux-3.15.3/arch/x86/ | wc -l
414
$ grep -rwn CONFIG_X86_64 linux-3.15.3/arch/x86/ | wc -l
472
$ grep -rn 'def.*CONFIG_X86_32' linux-3.15.3/arch/x86/ | wc -l
341
$ grep -rn 'def.*CONFIG_X86_64' linux-3.15.3/arch/x86/ | wc -l
403
$ find linux-3.15.3/arch/x86/ -name '*_32.[ch]' | wc -l
59
$ find linux-3.15.3/arch/x86/ -name '*_64.[ch]' | wc -l
61
$ find linux-3.15.3/arch/x86/ -name '*_32.[chS]' | wc -l
81
$ find linux-3.15.3/arch/x86/ -name '*_64.[chS]' | wc -l
101

so after several years(!) of effort there're almost as many exceptions as 'unified' files, or in other words, it wasn't done because i386/amd64 are the same arch (which is, ironically, something you'd know yourself if you *actually* worked with these archs). so you tell me who's treating marketing BS as a gospel of truth.

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 6, 2014 12:46 UTC (Sun) by roblucid (guest, #48964) [Link]

khim: just stick to your 16bit 8088 and 80286 programs, OK :)

Everyone else will use a -march value that is x86-64

The CHERI capability model: Revisiting RISC in an age of risk (Light Blue Touchpaper)

Posted Jul 7, 2014 14:20 UTC (Mon) by rriggs (guest, #11598) [Link]

This goes down as the stupidest argument I have ever witnessed on LWN. Congratulations.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds