From: anonymous c. <nas...@ya...> - 2007-04-18 04:48:30
|
> > [CR9...CR15 outside PM64] > I'd rather assume orthogonality now, and remove it later if necessary. I just don't want INTC/AMD to get any stupid ideas on this front. :) That LOCK prefix stuff is ugly. They should have introduced CR[1567] as an alias to CR8, and deprecated CR8 at the same time. But... sadly the x86 processor design world has to drag its mistakes around for a long time. > > [REX32] > Well, REX32 would be a significant project all on its own, and at the > moment I don't think anyone in this group except perhaps yourself > actually has enough information on it to implement it. Not that I'm > opposed to it, but without docs it's hard to do a good job. REX32 really isn't too difficult. There are only two (very simple) new instructions: STX and CLX. The rest falls out naturally, assuming that everything in insns.dat was annotated properly. As for new assembler modes, it's REX32 and ALL32. (The latter emits code that works for both 32 and REX32 mode, i.e. their shared subset.) But yeah, unless your target audience develops x86 processors, REX32 is pretty low priority. And even then you might not care. (INTC didn't seem to.) > >>> 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. :-) > > Alternate encodings, though, is a whole other ball of wax. Right now, > we definitely haven't attempted to make it possible to generate all > possible encodings, so that, too, is another project entirely. My > feeling is that it's better to have the programmer-friendly behavior we > currently have, and then worry about alternate encodings as a separate > project. As for alternate encodings, I'm using ALT.n prefixes, whereas n=0...31. For n=0 you get the first/default match. For n>0 you get the nth alternative encoding. If n>max, then you get the first/default again (and a warning). The last ALT.n takes precedence, and the user is advised to double-check. Probably not perfect... but hey, it was fairly easy to implement this. I could provide a list of which instructions are affected -- my insns.dat is annotated for this. Btw, I don't recall whether I filed an SF RFE for this though; I can't seem to find one right now. > > PS: These are just my $0.02. I don't hold a strong > > opinion on where NASM goes -- I addressed that > > issue by forking, a long time ago. No offense. > > None taken. Open source is like that. Different goals. Yup. > It's too bad we weren't able to use any of your work. Who knows. I haven't given up hope yet. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |