NASM 0.98.39 vs. NASM 2.03.01 disassembly
in [ASM]
|
Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Chuck Crayne on 22 Aug 2008 18:02 On Fri, 22 Aug 2008 23:34:36 +0200 Herbert Kleebauer <klee(a)unibwm.de> wrote: > Sadly the NASM macro system isn't powerful > enough to really "make" it a logical syntax. There has been some discussion among the NASM developers about adding a more powerful macro system. What features would you like to see? -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Chuck Crayne on 22 Aug 2008 18:58 On Fri, 22 Aug 2008 04:10:42 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > I'm not sure why you used "emulated" in this sentence... Perhaps this quote from Gabriel Torres' tutorial "Inside Pentium M Architecture" <http://www.hardwaresecrets.com/article/270/4> will explain it: "Since the introduction of P6 architecture with Pentium Pro Intel processors use a hybrid CISC/RISC architecture. The processor must accept CISC instructions, also known as x86 instructions, since all software available today is written using this kind of instructions. A RISC-only CPU couldnât be create for the PC because it wouldnât run software we have available today, like Windows and Office. So, the solution used by all processors available on the market today from both Intel and AMD is to use a CISC/RISC decoder. Internally the CPU processes RISC-like instructions, but its front-end accepts only CISC x86 instructions." In other words, the cpu is a super-scalar RISC-like engine wrapped in a layer of microcode which emulates the earlier x86 processors. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Chuck Crayne on 22 Aug 2008 19:34 On Fri, 22 Aug 2008 04:10:42 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > But, it's not just a matter of size, the encoding is important. In > the bits used to encode an instruction, a 16-bit instruction can > encode only two sizes of register: 8-bit and 16-bit. 32-bit > instruction: 8-bit and 32-bit. The mode and overrides determine if > the non-8-bit register will be 16-bit or 32-bit. Not sure what holds > for 64-bit. This is not quite correct. The bit which determines 8-bit vs full size is part of the opcode itself, and only certain instructions have this bit. For example, in the case of MOV reg, reg/mem the width bit is the low order bit of the first byte. Therefore, opcode 88h is an 8-bit move, while opcode 89h is a full-size move, where the value of full-size is, as you say above, determined by the default bit in the code segment descriptor, and the appropriate overrides. However, none of the protection control instructions, which include both LAR and LSL, has a width bit, and therefore none of these instructions is affected by either the mode or the overrides. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Rod Pemberton on 22 Aug 2008 22:16 "Chuck Crayne" <ccrayne(a)crayne.org> wrote in message news:20080822155808.79b62eb3(a)thor.crayne.org... > On Fri, 22 Aug 2008 04:10:42 -0400 > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > > > > I'm not sure why you used "emulated" in this sentence... > > [snip CISC via RISC] > >In other words, the cpu is a super-scalar RISC-like engine wrapped in a >layer of microcode which emulates the earlier x86 processors. (Since you said "RISC-like", I won't start in on you or Gabriel Torres indicating that the later Pentiums core qualify as RISC... I'll use "RISC-ish" so you know what I'm referring to although that's not correct either...) I don't usually refer to that as "emulation". Emulation, to me, implies a system which can't execute the code natively. A CISC cpu using a "RISC-ish" core can execute the instructions natively as CISC. It can't execute anything user provided on the "RISC-ish" core. It can only execute translated or converted to "RISC-ish" instructions from CISC instructions on the "RISC-ish" core. So, I tend to think of this as translation, conversion, etc. RP
From: Chuck Crayne on 23 Aug 2008 00:20
On Fri, 22 Aug 2008 22:16:55 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > (Since you said "RISC-like", I won't start in on you or Gabriel Torres > indicating that the later Pentiums core qualify as RISC... In my view, true RISC has been dead for many years now. The original RISC concept was that by supporting only a few basic instructions, it would be possible to execute one instruction in each machine cycle. A goal which, of course, has long since been surpassed. Unfortunately, however, RISC became more of a marketing term than a technical one, and I still know a number of otherwise highly respected computer professionals who commonly use RISC as a synonym for Unix. > Emulation, to me, implies a > system which can't execute the code natively. Historically, at least in the IBM world, emulation implied that the translation was done, at least in part, by microcode, whereas simulation implied that the translation was done entirely by software. However, I recognize that, over the years, this distinction has been lost. So, whatever you choose to call it is OK with me. The point remains, however, that the P6 had 40 80-bit registers, and a register renaming routine which allowed [e.g.] multiple EAX registers containing different values to be in existence at any one time. Since then, both the number and length of these re-nameable registers have increased. So, when speaking about the physical CPU, there is nothing at which one can point and truthfully say "This is an EAX register." In fact, none of the traditional x86 registers is anything but a transitory state of the ROB (Retirement Order Buffer) -- Chuck http://www.pacificsites.com/~ccrayne/charles.html |