#324 Document Intel's R8L-R15L aliases for R8B-R15B

[Anonymous]

Hi everyone,

The 'Intel 64 and IA-32 Architectures Software Developer's Manual, Volume1: Basic Architecture'
Order Number: 253665-022US, November 2006 seems to indicate on page 3-17 Table 3-2, that the
new general purpouse registers introduced in the 64-bit submode of IA-32e mode, are also addressable
as byte registers. The Table 3-2 on page 3-17 of the manual seems to clearly indicate 'R8l-R15l'
as byte addressable versions of thgese registers accessible through isnertion of the proper REX
prefix. This seems to be also implied when reading the first paragraph following the table.

So it should be possible to address the 8 new general purpouse registers as byte addressable as the
manual indeictes in the table ( the code snippet is for demo only, it's not supposed to do anything
meaningful )

mov [rbx], r8l
mov [rbx], r9l
mov [rbx], r10l
mov [rbx], r11l
mov [rbx], r12l
mov [rbx], r13l
mov [rbx], r14l
mov [rbx], r15l

Here is what running nasm -f elf64 lprSum.asm returns:
lprSum.asm:38: error: symbol `r8l' undefined
lprSum.asm:39: error: symbol `r9l' undefined
lprSum.asm:40: error: symbol `r10l' undefined
lprSum.asm:41: error: symbol `r11l' undefined
lprSum.asm:42: error: symbol `r12l' undefined
lprSum.asm:43: error: symbol `r13l' undefined
lprSum.asm:44: error: symbol `r14l' undefined

Either the manual is wrong ( a possibility ) or this access mode was accidentally left out of this
version of NASM ( another possibility ) or I am missunderstanding both the manual and nasm's
capabilties ( also possible ).

Thanks nevertheless for provoding us with NASM which has become an indispensible tool in our
work.

Regards

Reza Mostafid

dar.beh.dar@gmail.com

Details:

I am running Fedora Core 7 LINUX, running on an Intel Core 2 Duo.

'rpm -q' returns 'nasm-1.99.99.91-1'
'nasm -verbose' returns 'NASM version 2.00rc1'

I searched for and downloaded the binaries as rpms from http://rpm.pbone.net/

[Nobody/Anonymous]

[nasm64developer]

Logged In: YES
user_id=804543
Originator: NO

AMD invented x86-64 (in the form of AMD64)
and decided to call them R8B...R15B. See
section 3.1.2 of #24592-3.14 for example.

Why Intel decided to name them R8L...R15L
in their version (EM64T, IA-32e, Intel 64,
or whatever they have been calling it over
the course of time) is a mystery to me.

Instead of adding yet more identifiers to
NASM that are always reserved, code that
wants to use R8L...R15L should use macros:

%idefine r8l r8b
...
%idefine r15l r15b

That way R8L...R15L only occupy name space
whenever they are actually needed/used.

[H. Peter Anvin]

Logged In: YES
user_id=58697
Originator: NO

Urk. What a bungle on Intel's part. It might be worth finding out what people expect; if there are enough people expecting to call them R8L etc then we probably should handle them natively anyway.

[nasm64developer]

Logged In: YES
user_id=804543
Originator: NO

Well, MASM doesn't support it:

Microsoft (R) Macro Assembler (x64) Version 8.00.50215.44 12/10/07 11:56:11
0.asm Page 1 - 1

00000000 .code

mov r8l,0
0.asm(3) : error A2006: undefined symbol : r8l
00000000 41/ B0 00 mov r8b,0

end
♀Microsoft (R) Macro Assembler (x64) Version 8.00.50215.44 12/10/07 11:56:11
0.asm Symbols 2 - 1

0 Warnings
1 Errors

I'd say Intel is on their own on this one. :-D

[H. Peter Anvin]

Logged In: YES
user_id=58697
Originator: NO

OK, this should be documented, however.

[H. Peter Anvin]

Logged In: YES
user_id=58697
Originator: NO

This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at ftp://ftp.zytor.com/pub/nasm/snapshots/; the snapshot robot usually runs some time between 09:00 and 10:30 UTC.

[H. Peter Anvin]

Logged In: YES
user_id=58697
Originator: NO

Checked into documentation.