Conditional compilation 32/64

[Joseph M. Newcomer]

I have studied all the @-symbols and various directives, and there does not appear to be a
built-in way to tell if I'm assembling code in 32-bit or 64-bit. For example, I might
want to do

if ...64-bit mode...
tax textequ rax
tbx textequ rbx
...etc
pointer typedef QWORD
else ... 32-bit mode
tax textequ eax
tbx textequ ebx
pointer typedef DWORD
endif

The idea being that if I'm passing an address and want to pick it up, I will need to use
either 32-bit or 64-bit moves, which I think I can fake using the "t-convention" notation
that Windows uses (LPTSTR, TCHAR, etc.)

So I can write

whatever PROC C uses tax, data:pointer
mov tax, data
...use thing pointed to...
mov tax, 0
ret
whatever ENDP

I'm trying to come up with some good programming examples for people who need to write
high-performance subroutines (usually using SIMD) in assembler. These will need to
assemble in both 32-bit and 64-bit.

Obviously, I can have them define a symbol on the command line, but if there's an
already-built-in way to do this, I'd rather use that.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[James Harris]

On 15 Jan, 06:33, Joseph M. Newcomer <newco...@flounder.com> wrote:

> I have studied all the @-symbols and various directives, and there does not appear to be a
> built-in way to tell if I'm assembling code in 32-bit or 64-bit.

It's easy in Nasm: the __BITS__ symbol contains 16, 32, or 64 as
needed. Sorry I don't know what Masm provides.

James

[Tim Roberts]

Joseph M. Newcomer <newc...@flounder.com> wrote:
>
>I have studied all the @-symbols and various directives, and there does not appear to be a
>built-in way to tell if I'm assembling code in 32-bit or 64-bit.

Correct. This is not too big of an issue, since 64-bit code requires a
different assembler (ml64). When you're creating the makefile, you can
just add a -D symbol for the ml64 command line. I use -DWIN64.

# Detect 64-bit builds.
!if [ml64 >nul 2>nul] == 0
BIN = x64\$(BIN)
AS = ml64 -DWIN64
!endif

>if ...64-bit mode...
>tax textequ rax
>tbx textequ rbx
>...etc
>pointer typedef QWORD
>else ... 32-bit mode
>tax textequ eax
>tbx textequ ebx
>pointer typedef DWORD
>endif

You don't really need the conditional for pointers:
pointer typedef PTR BYTE

>Obviously, I can have them define a symbol on the command line, but if there's an
>already-built-in way to do this, I'd rather use that.

I, like you, have never found one.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[David Craig]

Microsoft usually prefers that you place the assembly source code files in
subdirectories that match their target processor. I think that for a memcpy
function the assembly would be different in that the various sized 'mov
string' instructions might be used. The IA64 is completely different and
using a single source file for it and another processor seems impossible.
Yes, some of us have to create IA64 versions.

"Tim Roberts" <ti...@probo.com> wrote in message
news:smr4l5tmh04f7ktbv...@4ax.com...

[Joseph M. Newcomer]

Consider, however, a program which is essentially unrelated to the platform (e.g., SIMD
instructions) but which has to use either 32-bit or 64-bit pointers, and E*X/R*X registers
to hold them. There would be no reason to maintain two source copies, and doing clumsy
things like putting the bodies in one file and the setup in another and using #include is
amazingly clumsy. Key here is that the compiler choice varies, but the source code is
essentially constant, except for pointer registers.
joe

[Joseph M. Newcomer]

It would, of course, have been completely reasonable for the assembler to provide this
information; that's probably why it wasn't done.

So I'll just use -DWIN64 on the command line.

Some of the existing MASM documentation is so unbelievably bad it is hard to imagine how
anyone could have approved it. So I was hoping that the failure to find this was the more
expected failure to document it.
joe

[Tim Roberts]

Joseph M. Newcomer <newc...@flounder.com> wrote:
>
>Some of the existing MASM documentation is so unbelievably bad it is hard to imagine how
>anyone could have approved it. So I was hoping that the failure to find this was the more
>expected failure to document it.

MASM really is the poor stepchild. Around 1992 or so, Microsoft actually
wrote reasonable documentation for MASM 6.0. I still have (and cherish!)
that printed doc. However, the assembler has changed rather significantly
at each major release since then (6.1, 6.2, 7.0, 8.0, 9.0), and as near as
I can tell, the documentation has never been updated.

Macros in MASM, for example, are a brand of magic just short of voodoo. A
hundred years ago, I was an ace in COMPASS, the assembler for Control
Data's mainframe. That was a well-crafted, well-documented, and sensible
assembler, with the best macro processor I've ever encountered. I've
missed it ever since.

Microsoft does, after all, want us all to believe that assembler doesn't
exist. It's almost enough to make me switch to one of the other
assemblers. Although they don't have the official blessing, they do have
active developer communities who are documenting everything they add.

[japheth]

On Jan 15, 7:33 am, Joseph M. Newcomer <newco...@flounder.com> wrote:
> I have studied all the @-symbols and various directives, and there does not appear to be a
> built-in way to tell if I'm assembling code in 32-bit or 64-bit.  For example, I might
> want to do
>
> if ...64-bit mode...
> tax textequ rax
> tbx textequ rbx
> ...etc
> pointer typedef QWORD
> else ... 32-bit mode
> tax textequ eax
> tbx textequ ebx
> pointer typedef DWORD
> endif

Using the TYPE operator one might get a reliable variable which helps
to distinguish between 32- and 64-bit:

IS_32 equ 0FF04h
IS_64 equ 0FF08h
ENV EQU TYPE PROC

if ENV EQ IS_64
...
else
...
endif