From: Keith K. <sp...@dy...> - 2007-04-18 04:46:06
|
>> > [*] And up to CR15D of course, once someone is >> > shipping a CPU with those CRx, and decides >> > that LOCK makes them visible outside PM64. >> > Until then CR9D...CR15D shouldn't work. >> >> Why? We allow cr1, cr5 etc which don't exist either. > > I am merely suggesting to hold off on CR9D...CR15D > until we know for sure that CR8D was not just some > sort of anomaly. (Why? Because the history of CR8D > suggests so. AMD should have used CR[1567] for the > TPR from the very beginning. They didn't. Then CR8 > became really popular, and AMD added the LOCK pre- > fixed variant for non-PM64. Will CR9...CR15 follow > suit? Who knows.) > >> > Why does this matter? Because of REX32 mode. >> >> ... which at least officially doesn't exist, either. > > Yeah, nobody acknowledges its existence... and yet > it was (and perhaps still is -- I have not checked > recently) shipping in K8. It was functional enough > to enter and exit the mode and execute a number of > instructions in it; whether it was 100% functional > is a different question, of course. > > Some x86 CPU knows what to do with it? Then a good > assembler better be supporting it! I mean, hey, it > is no different than, say, the FRSTPM instruction, > which used to work on the 80287XL. At least that's > how I look at this stuff. :-) > >> > 000A 440F20C0 <0> mov eax,cr8 >> > 000E F00F20C0 <0> mov eax,cr8d >> >> And, pray tell, what would be the difference between these two >> supposedly different instructions, other than encoding? > > Precisely... their encoding. :-) > Well, I believe that line of thinking must yield to the K.I.S.S. method, else we create unneeded and uncommon complexity... something I think that is a big factor in why people use Intel-based syntax and avoid AT&T syntax like the plague. In other words, let's try to deviate from the docs as little as possible. We are comparing our ideas to companies like AMD and Intel who have the man-power and insight to properly "dictate" technology and the respective terminology. Let's simply take their wisdom and build NASM around it. |