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 12:08 Chuck Crayne <ccrayne(a)crayne.org> wrote in part: > 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. Yes, but was extended by parallel execution -- RISC cores went quad-issue long ago while x86 still is stuck at triple issue, possibly due to flag dependencies. > Unfortunately, however, RISC became more of a marketing > term than a technical one, I would dispute the "unfortunately". As I see it, IA64 (Itanium) was a logical development of RISC and had it been possible to make it succeed, Intel would have. It was not, because adaptive dynamic hardware (like ROB) cannot be replaced by static software (compiler scheduling). This compiler failure is indirectly positive for ASM. That said, RISC is far from dead. ARM is RISC and owns the low-power market. To the extent computing is heat/power-limited, ARM++ may make a place in server farms and compute clusters. Linux & NetBSD (at least) are available as full environments. Only the hardware (MB cache, quad core 3 GHz ARMs) is lacking. > and I still know a number of otherwise highly respected computer > professionals who commonly use RISC as a synonym for Unix. LOL! > 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. Indeed. CPU developement has been very incremental since the 10 year old iP6 and aK6 cores. AFAICS, the basic triple-issue ROB, dispatch and retirement are unchanged. Rename registers and other buffers have been added with some execution engines and increased pipelineability. Even 64 is just width and decode. Nothing like the transition from the dual-issue iP5 (original Pentium/MMX). -- Robert
From: Phil Carmody on 23 Aug 2008 13:59 Chuck Crayne <ccrayne(a)crayne.org> writes: > 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? All those of m4. .... think about it ... Phil -- The fact that a believer is happier than a sceptic is no more to the point than the fact that a drunken man is happier than a sober one. The happiness of credulity is a cheap and dangerous quality. -- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion
From: Herbert Kleebauer on 23 Aug 2008 16:05 Chuck Crayne wrote: > 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? I'm not a NASM user and therefore surely not in position to make suggestions for the NASM development. A year ago I did some experiments with NASM macros (I wanted to show Frank that NASM can already do much better than it's standard syntax), but I really missed some simple string manipulating functions which would allow me to process the macro parameters character by character (for example to use _ instead of . for local labels or use () instead of [] for indirect addressing). I would like to see a text pre-processing subsystem (completely independent from the macro subsystem) which is called by NASM with each source code line read. This subsystem then can modify or replace the original source code line and then give it back to NASM for normal processing (including macro expansion). This pre-processing sub system must be programmable, so maybe the best would be to include an already existing GPLed BASIC or FORTH interpreter. An other way would be to implement a simple virtual machine (a few instructions, 64k code, data and stack should be enough so only a few lines of C code should be necessary to implement it). With such a pre-processing sub system any NASM user can easily define his preferred syntax (by loading the appropriate program for the interpreter from the assembly source code file or an include file). 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.
From: NathanCBaker on 23 Aug 2008 17:08 On Aug 23, 4:05 pm, Herbert Kleebauer <k...(a)unibwm.de> wrote: > > I would like to see a text pre-processing subsystem (completely > independent from the macro subsystem) which is called by NASM > with each source code line read. This subsystem then can modify > or replace the original source code line and then give it back to > NASM for normal processing (including macro expansion). This > pre-processing sub system must be programmable, so maybe the best > would be to include an already existing GPLed BASIC or FORTH > interpreter. An other way would be to implement a simple virtual > machine (a few instructions, 64k code, data and stack should be > enough so only a few lines of C code should be necessary to implement > it). I nominate the public domain HLABasic2 to fill this task: http://hlaex.svn.sourceforge.net/viewvc/hlaex/generic/HLABasic2/ > > With such a pre-processing sub system any NASM user can easily define > his preferred syntax (by loading the appropriate program for the > interpreter from the assembly source code file or an include file). > 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! :) Nathan.
From: Chuck Crayne on 23 Aug 2008 17:03
On Sat, 23 Aug 2008 16:08:41 GMT Robert Redelmeier <redelm(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. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html |