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 9 Sep 2008 19:56 On Tue, 9 Sep 2008 18:22:28 -0400 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > Although given the very early timeframe of your expertise, I do have > to wonder how closely your understanding of the early technology > matches that of post-1975 microprocessors. If you compare the technology time-line of mainframes with that of micro-computers, you will see that the mainframes have typically been about twenty years ahead. For example, the IBM 360 series, introduced in 1965, was a 32-bit architecture, with 16 general purpose and 16 floating point registers. It could address 16 megabytes of real memory, although nobody could afford anywhere near that much. It had protected mode instructions, and multiple storage protection keys. It had an instruction set which included not only fixed and floating point arithmetic, but variable length fixed point decimal operations which could handle up to 31 decimal digits, as well as a rich set of storage to storage moves. If you want to challenge me on designing out of order execution engines, register renaming logic, or dynamic branch prediction circuitry, then my practical experience is zilch, although I understand the theory. > I think my understanding > is about as well developed as one can expect for someone not in > circuit design, and far above that of the common programmer. No argument there. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Chuck Crayne on 9 Sep 2008 23:35 On Mon, 8 Sep 2008 22:29:08 -0700 (PDT) NathanCBaker(a)gmail.com wrote: > Could I trouble you for an instruction list (w/opcodes)? Because it was an unannounced product, the design documentation wasn't allowed to leave the building, and by the time the machine was brought to market, I was working for IBM. So I have no instruction list to share with you. However, I can give you some background information. The Century series (codenamed the "615") was NCR's response to the IBM 360 family. In particular, the 615-100 was designed to compete with the 360/30. So, its architecture was similar to IBM's. However, it was not a clone. It was byte addressable, which was a major change from the previous NCR architecture, which used 12-bit "slabs", each of which could contain either two 6-bit characters, or three 4-bit binary coded digits. But, in the new byte architecture, NCR decided to use ASCII character encoding, instead of IBM's EBCDIC. The console was a model 33ASR Teletype, and the I/O channels were designed for compatibility with NCR's existing line of tape handlers, printer, etc. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Wolfgang Kern on 10 Sep 2008 07:07 Rod Pemberton wrote: .... > The issue originally came up with SETcc (and MOVZX), not LAR/LSL. My code > was using only 32-bit registers, but at the time I needed an instruction > which doesn't exist: SETcc r32. But, x86 has SETcc r8. .... I may not understand at all why a single bit result (from SETcc) have to be presented in 32 bits. CMOVcc seem to be the solution designed for HLL true/false 'flags' [macros]... > After expanding all that you'll end up with a 40 lines of code... > The thought that came up for me was: > "Why can't I simply pass eax, ebx, ecx, edx, ebp, esp, esi, edi > to some function and get an appropriate register for SETcc and MOVZX? Your demand for lowbyte access of all registers for MOVZX/SX and SETcc seem to be already covered in long mode, ie: 40 0f b6 c4 MOVZX eax,spl ;from low byte of RSP 40 0f 94 c5 SETz bpl ;affects only low byte of RBP Why you want to convert conditions into 0 or 1 in 32-bit registers ? Oh.. 'C' is the target ... :) __ wolfgang
From: Rod Pemberton on 10 Sep 2008 14:19 "Wolfgang Kern" <nowhere(a)never.at> wrote in message news:ga89u2$7gm$1(a)newsreader2.utanet.at... > Rod Pemberton wrote: > ... > > The issue originally came up with SETcc (and MOVZX), not LAR/LSL. My code > > was using only 32-bit registers, but at the time I needed an instruction > > which doesn't exist: SETcc r32. But, x86 has SETcc r8. > > I may not understand at all why a single bit result (from SETcc) > have to be presented in 32 bits. Bunch of macro's for a code generator. 32-bit only registers. "No" flags (Well, minimal...). No 8-bit. > CMOVcc seem to be the solution designed for HLL true/false 'flags' Not supported on older cpu's. Requires the use of CPUID. CPUID isn't supported on older cpu's. > [macros]... > > After expanding all that you'll end up with a 40 lines of code... > > The thought that came up for me was: > > "Why can't I simply pass eax, ebx, ecx, edx, ebp, esp, esi, edi > > to some function and get an appropriate register for SETcc and MOVZX? > > Your demand for lowbyte access of all registers for MOVZX/SX and SETcc > seem to be already covered in long mode, ie: > > 40 0f b6 c4 MOVZX eax,spl ;from low byte of RSP > 40 0f 94 c5 SETz bpl ;affects only low byte of RBP Nice. But, I've already eliminated use of SETcc for 32-bit code... > Why you want to convert conditions into 0 or 1 in 32-bit registers ? > Oh.. 'C' is the target ... :) :) Well, I'm working on it anyway... It's not going real fast or well. :-) I may end up with something other than C. ;) Yeah, if I'd have designed SETcc, it would've set the largest sized register for the mode or would've set the CF for use with SBB. Rod Pemberton
From: Wolfgang Kern on 10 Sep 2008 14:55
Rod Pemberton replied: >> I may not understand at all why a single bit result (from SETcc) >> have to be presented in 32 bits. > Bunch of macro's for a code generator. 32-bit only registers. "No" flags > (Well, minimal...). No 8-bit. >> CMOVcc seem to be the solution designed for HLL true/false 'flags' > Not supported on older cpu's. Requires the use of CPUID. CPUID isn't > supported on older cpu's. You still work at the 486-museum ? :) For less than 300 bucks you can get a complete PC of today/yesterday... >> [macros]... >>> After expanding all that you'll end up with a 40 lines of code... >>> The thought that came up for me was: >>> "Why can't I simply pass eax, ebx, ecx, edx, ebp, esp, esi, edi >>> to some function and get an appropriate register for SETcc and MOVZX? \>> Your demand for lowbyte access of all registers for MOVZX/SX and SETcc >> seem to be already covered in long mode, ie: >> 40 0f b6 c4 MOVZX eax,spl ;from low byte of RSP >> 40 0f 94 c5 SETz bpl ;affects only low byte of RBP > > Nice. But, I've already eliminated use of SETcc for 32-bit code... good, and it wont make much sense anyway, unfortunately BTx instuctions weren't speed up on latest AMDs (because windoze-coders and C may not know that 'Bits' really exist ?) >> Why you want to convert conditions into 0 or 1 in 32-bit registers ? >> Oh.. 'C' is the target ... :) > :) > Well, I'm working on it anyway... It's not going real fast or well. :-) > may end up with something other than C. ;) TrueCode(tm)-fans better stay away from HLL (worst case==C/C+-) > Yeah, if I'd have designed SETcc, it would've set the largest sized > register for the mode or would've set the CF for use with SBB. OTOH I prefer "Bits", to hold 32 different states and combinations within a dword ... Yeah, we can convert all CC into Carry (in macros) to make ADC/SBB work like ADZ/SBZ (which I'd had in the instruction list). (note for AMD-designers: I'd like to see "CMOVcc b/w/d/q r/m,immediate" perhaps instead/or in the range of the now redundant 3Dnow! codes) __ wolfgang |