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: Robert Redelmeier on 23 Aug 2008 18:28 Chuck Crayne <ccrayne(a)crayne.org> wrote in part: > It is not the technology which I am disputing, but merely the > continued use of obsolete terminology. In the literal sense > of the acronym, ARM is definitely not RISC. Not only does > ARM have a large number of instructions, including multiple > multiply instructions, but it even has (Oh horror of horrors) > a divide instruction. > In the original RISC concept, such inherently time consuming > instruction were anathema. Agreed. The temptations of microcode were too hard to resist! -- Robert
From: Alexei A. Frounze on 23 Aug 2008 21:39 On Aug 23, 2:03 pm, Chuck Crayne <ccra...(a)crayne.org> wrote: > On Sat, 23 Aug 2008 16:08:41 GMT > > Robert Redelmeier <red...(a)ev1.net.invalid> wrote: > > ARM is RISC and owns the > > low-power market. > > It is not the technology which I am disputing, but merely the continued > use of obsolete terminology. In the literal sense of the acronym, ARM is > definitely not RISC. Not only does ARM have a large number of > instructions, including multiple multiply instructions, but it even has > (Oh horror of horrors) a divide instruction. > > In the original RISC concept, such inherently time consuming > instruction were anathema. I guess these days the technology is advanced enough to consider a bunch of multiply and divide instruction RISCy enough. :) And if one considers the hardware multiplier implementation, just one signed implementation with enough bits can do unsigned, signed and mixed (signed x unsigned) multiplication. So, the multiplication instruction opcode is just another input to that same multiplier. I'd say not such a big deal. Alex
From: Herbert Kleebauer on 24 Aug 2008 15:11 NathanCBaker(a)gmail.com wrote: > > pre-processing sub system must be programmable, so maybe the best > > would be to include an already existing GPLed BASIC or FORTH > > interpreter. > I nominate the public domain HLABasic2 to fill this task: > > http://hlaex.svn.sourceforge.net/viewvc/hlaex/generic/HLABasic2/ But only if you rewrite it in C. NASM processes x86 assembly source code and generates x86 machine code, but that doesn't mean that NASM only runs on a x86 system. It is a real bad idea to to write an assembler (or part of it) in assembly language and therefore make it CPU dependent. > > On the other side, this could lead to completely different looking > > NASM source code files. NASM can compile them all, but no NASM > > user will be able to easily read or understand a NASM source > > written by somebody else. > An ideal goal! :) Because the number of assemblers is already larger than the number of assembly programmers, this really doesn't matter.
From: Martin Str|mberg on 25 Aug 2008 13:22 Frank Kotler <fbkotler(a)verizon.net> wrote: > global _start > section .text > _start: > nop > mov ebx, -1 > mov bx, ds > lsl eax, bx > lsl eax, ebx > lsl eax, [last_word] > mov eax, [last_word] ; segfault! (but not with ax) > mov eax, 1 > int 80h > align 16 > code_size equ $ - $$ > section .data > times 4096 - code_size + 20h - 2 db 0 > last_word dw 2Bh I've tried this, but I can't figure out how you are supposed to link this sucker. All I get is segmentation fault or silent failure to run it at all. BTW, my nasm (a old one, I think) refuses to assemble "lsl eax, ebx". Please tell me how, for Linux ELF and DJGPP. -- MartinS
From: Frank Kotler on 25 Aug 2008 16:25
Martin Str|mberg wrote: > Frank Kotler <fbkotler(a)verizon.net> wrote: >> global _start > >> section .text > >> _start: >> nop >> mov ebx, -1 >> mov bx, ds >> lsl eax, bx >> lsl eax, ebx > >> lsl eax, [last_word] >> mov eax, [last_word] ; segfault! (but not with ax) > >> mov eax, 1 >> int 80h > >> align 16 >> code_size equ $ - $$ > >> section .data >> times 4096 - code_size + 20h - 2 db 0 I've been afraid someone's going to ask me what the "+20h" is for. Pure fudge! Determined by trial-and-error to put "last_word" where I want it... >> last_word dw 2Bh > > I've tried this, but I can't figure out how you are supposed to link > this sucker. ld -o myfile myfile.o > All I get is segmentation fault or silent failure to run > it at all. Well, it doesn't "do" anything, so if it doesn't segfault, it's silent. Intended to be stepped through in a debugger, rather than "run", really... To "prove" anything the "mov eax, [last_word]" should be changed to ax, or deleted. If it still segfaults on some processor, then lsl *is* reading 32 bits like the manual says. Could be true. I'd be surprised, but only a little... > BTW, my nasm (a old one, I think) refuses to assemble "lsl eax, ebx". If it's really old, "nasm -r" will spit up the version number. "nasm -v" works for newer ones. As you can see, lsl and lar are "controversial" how/if they should be assembled/disassembled. 0.98.39 doesn't like "lsl eax, bx"... You can always get the very latest from: ftp://ftp.zytor.com/pub/nasm/snapshots Today's snapshot fixes two bugs reported by Agner Fog - AVX instructions and "movsxd"... you probably won't encounter them... Speaking of new versions, Agner Fog's "objconv" now has a "-fnasm" switch to disassemble into Nasm syntax!!! http://www.agner.org/optimize/#objconv > Please tell me how, for Linux ELF and DJGPP. I think "ld -o outfile infile.o" would work for DJGPP as well(?). The "int 80h" won't work in DJGPP, of course, but you could still step through it with a debugger (maybe... dunno where "last valid word" would be with DJGPP). If you *do* see that little experiment segfault on the lsl, let us know what CPU. The manual *does* suggest that it will (used to). Best, Frank |