From doynax at gmail.com  Sat May 10 12:35:21 2008
From: doynax at gmail.com (doynax)
Date: Sat, 10 May 2008 21:35:21 +0200
Subject: Feature request: debuggable macros
Message-ID: <bff8f6480805101235x69449d45x98401b3a9a9d4a84@mail.gmail.com>

I'm currently working on a project where the assembler code consists almost
entirely of macros. And currently this makes development with YASM very
frustrating due to the fact that the debugging information treats entire
macros as a single statement. Would it be feasible to use the line numbers
of the instructions within in the innermost macro body instead? This ought
to be the preferred behavior in almost all cases but perhaps binding
statements to the same source line is problematic.
Similarly syntax errors within macros are also reported only for the
outermost macro invocation. Perhaps warnings and errors could be reported
the entire macro chain?

I took a quick peek at the source but realized I wouldn't have much chance
without first studying the design of YASM, and I suspect that these are
either trivial fixes for someone familiar with the code or they'll require
significant redesign of the internal datastructures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cvs.tortall.net/pipermail/yasm-devel/attachments/20080510/25942412/attachment.html 

From doynax at gmail.com  Mon May 12 00:30:56 2008
From: doynax at gmail.com (doynax)
Date: Mon, 12 May 2008 09:30:56 +0200
Subject: Feature request: debuggable macros
In-Reply-To: <ebdbbc900805111946m5dda9ba3yf26a1a97bad17f26@mail.gmail.com>
References: <ebdbbc900805111946m5dda9ba3yf26a1a97bad17f26@mail.gmail.com>
Message-ID: <bff8f6480805120030k72ebc58fv98c014b53871069b@mail.gmail.com>

On Mon, May 12, 2008 at 4:46 AM, anonymous coward
<nasm64developer at users.sf.net> wrote:
> > I'm currently working on a project where the assembler code consists almost
> > entirely of macros. [...]
>
> Can you provide sample code?

Sure, though it's a bit straightforward. Lets say you have the
following stupid little float-to-int converter and are trying to
assemble it, with debugging information, for Visual Studio:

	bits 32

	%macro doit 0
	sub esp,4
	fld dword [esp+8]
	fistp dword [esp]
	pop eax
	ret
	%endmacro

	global _ftoi
_ftoi: ;int __cdecl _ftoi(float)
	doit

Now, trying to run this through the debugger does result in it
stepping once line per instruction, as it should, but with the cursor
staying put at the macro invocation point rather than moving through
the macro's instructions as would be more useful. I suppose the ideal
solution would be to fake a call stack somehow for each macro level
but I doubt that's possible or worth the effort.
Perhaps for certain tiny utility macros, say a multiple push sequence,
the current scheme might be more useful. But for anything less
foolproof than that you pretty much want to see what's going on.

In my case my assembler code primarily consists of a set of software
blitters where various types of graphics operation are combined with
various ways of fetching source pixels to create the functions, plus
there are some specializations for different instruction sets and
such. This results in two or three levels of macros where the entire
functions are generated entirely from macros rendering the debugging
information virtually useless. And with the current mess of
instruction sets to support I rather think I'm not alone with this
kind of setup..

As for the error issue lets say you forgot to specify the size of the
store then what you get from the assembler is the proper "invalid size
for operand 1" message but reported for the line of the macro
invocation. Reasonable behavior here would be to dump the entire macro
heirachy when something goes wrong as most assemblers tend to do.
Anyway as you can imagine this leads to a lot of manual binary
searching whenever something goes wrong, which is both time consuming
and error prone (e.g. forgetting to comment something back in again).

From peter at tortall.net  Wed May 14 19:17:39 2008
From: peter at tortall.net (Peter Johnson)
Date: Wed, 14 May 2008 19:17:39 -0700 (PDT)
Subject: ANNC: Yasm 0.7.1
Message-ID: <20080514191710.L70000@cvs.tortall.net>

I'm pleased to announce the availability of Yasm 0.7.1.  This is primarily a 
bugfix release.

Changes from 0.7.0 to 0.7.1 include:
     - AVX instruction bugfixes (0.7.0 errata)
     - Build fixes (crashes on some machines)
     - Minor CPU flags fixes

Changes from 0.6.2 to 0.7.0 included:
     - Intel Advanced Vector Extensions (AVX) instruction support.
     - Multi-section binary support in the NASM style (see #71, #99,
       [2010]).
     - Add support for ELF32 and ELF64 TLS (thread local storage)
       relocations.
     - Allow use of 0X in addition to 0x to prefix hex constants (#127).
     - Allow underscores in hex, binary, and octal constants (e.g.
       0111_1111b)
     - Fix memory sizes on SSE/SSE2 instructions (#119).
     - Allow standalone prefixes (#122).
     - Simplify new varieties of sym-sym values (#124).
     - Support SAFESEH directive for win32 SEH handlers (#130).
     - Enable sym at FOO constructs in GAS parser.
     - SSE5 condition code support.
     - Other bugfixes.

Known issues with this release can be found in the Yasm Trac ticket system.

Release Notes for 0.7.1:

http://www.tortall.net/projects/yasm/wiki/Release0.7.1

Downloads from the Yasm website include .tar.gz source (for Unix systems)
and Win64, Win32, CygWin, and DOS executables:

http://www.tortall.net/projects/yasm/wiki/Download

Please download, test, and tinker, and most importantly, send comments and bug 
reports!  Thanks to all those who submitted bug reports and contributed code 
for this release.  Special thanks go to nasm64developer for AVX bug reports. 
More developers are always welcome to join us.

Thanks,
Peter Johnson and the other Yasm developers
<peter at tortall.net>

Yasm development discussion is at <yasm-devel at tortall.net>.


From dfeustel at mindspring.com  Wed May 14 20:36:20 2008
From: dfeustel at mindspring.com (Dave)
Date: Wed, 14 May 2008 20:36:20 -0700 (PDT)
Subject: [yasm-announce] ANNC: Yasm 0.7.1
In-Reply-To: <20080514191710.L70000@cvs.tortall.net>
Message-ID: <20080515033621.CCB2C17105@cvs.tortall.net>

On Wed, May 14, 2008 at 07:17:39PM -0700, Peter Johnson wrote:
>I'm pleased to announce the availability of Yasm 0.7.1.  This is primarily a 
>bugfix release.
>
>http://www.tortall.net/projects/yasm/wiki/Download
>
>Please download, test, and tinker, and most importantly, send comments and bug 
>reports!  Thanks to all those who submitted bug reports and contributed code 
>for this release.  Special thanks go to nasm64developer for AVX bug reports. 
>More developers are always welcome to join us.
>
>Thanks,
>Peter Johnson and the other Yasm developers
><peter at tortall.net>
>
>Yasm development discussion is at <yasm-devel at tortall.net>.

I successfully built and installed yasm 7.1 on 64-bit FreeBSD 7.0 release.  I
found no example test .asm files, so I created a test file consisting of the
output of find . -name '*.asm' command in the yasm directory. I edited the file
to have yasm -f elf64 -g dwarf2 ' in front of each filename and then ran it.
Got a lot of errors, but am not sure what to make of them since my assembler
knowledge is really rusty. I'm looking forward to playing with the AVX
instruction capability.

Dave Feustel

From peter at tortall.net  Wed May 14 23:01:52 2008
From: peter at tortall.net (Peter Johnson)
Date: Wed, 14 May 2008 23:01:52 -0700 (PDT)
Subject: [yasm-announce] ANNC: Yasm 0.7.1
In-Reply-To: <20080515033621.D22401786A@cvs.tortall.net>
References: <20080515033621.D22401786A@cvs.tortall.net>
Message-ID: <20080514225625.E94875@cvs.tortall.net>

On Wed, 14 May 2008, Dave wrote:
> I successfully built and installed yasm 7.1 on 64-bit FreeBSD 7.0 release.  I
> found no example test .asm files, so I created a test file consisting of the
> output of find . -name '*.asm' command in the yasm directory. I edited the file
> to have yasm -f elf64 -g dwarf2 ' in front of each filename and then ran it.
> Got a lot of errors, but am not sure what to make of them since my assembler
> knowledge is really rusty. I'm looking forward to playing with the AVX
> instruction capability.

There are numerous test .asm files in the various modules/.../tests/ 
directories, as you discovered.  Running "make test" will go through and 
assemble each one.  However, they're not really "example" files but rather 
tests of various yasm functionality.  Most of the non-objfmt test files 
are intended for binary output; the sh script in each test directory 
contain the command line options used for testing.  For the exhaustive AVX 
tests, see modules/arch/x86/tests/avx.asm, avxcc.asm, clmul.asm, and 
aes.asm.  Again, these are not "example" files but rather exhaustive tests 
of the AVX instructions.

Peter