Is PSHUFW instruction MMX or SSE or SSE2? Is NASM manual correct?
Rod Pemberton
I updated to Adobe's Flash to r119 from r47. FLASH9E.OCX is "blowing
chunks" (invalid instruction) on what appears to be a PSHUFW instruction for
an AMD K6-2. I've found a few illegal instruction complaints regarding
PSHUFW for AMD K6-2's, K6-3's, Celeron's, etc. According to some NG posts,
the reason is that PSHUFW isn't an MMX instruction but an SSE or SSE2
instruction. Can someone in the confirm that this is correct? The NASM
0.98.39 manual says PSHUFW is MMX, not SSE. What about the current NASM
manual?
PSHUFW mm1,mm2/m64,imm8 ; 0F 70 /r ib [KATMAI,MMX]
Rod Pemberton
Charles Crayne
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote:
> According to some NG posts,
> the reason is that PSHUFW isn't an MMX instruction but an SSE or SSE2
> instruction.
The Intel manual shows it as an SSE instruction.
> What about the current NASM manual?
The current NASM manual current does not have an instruction list, but
the internal table has not changed.
-- Chuck
H. Peter Anvin
There are a set of MMX instructions which are considered part of the
SSE-1 feature set by Intel. Those are tagged [KATMAI,MMX] in the NASM
instruction table, as they are technically MMX instructions. From a
feature-detection standpoint, one should look for the SSE feature bit
*OR* the MMXEXT feature bit in the extended (AMD) instruction space (AMD
has some K7-class processors which have these instructions, but no real
SSE instructions.)
-hpa
Betov
@thor.crayne.org:
> The current NASM manual current does not have an instruction list, but
> the internal table has not changed.
Why? Times ago i got an "AppendixA" from the NASM Documentation,
that had been reviewed by Debs, and which was rather clean. Why
was it removed?
Betov.
Rod Pemberton
"H. Peter Anvin" <h...@zytor.com> wrote in message
news:476E03...@zytor.com...
Thank you.
Wouldn't it be better to tag them by the required feature bit, not the
potential instruction usage or cpu class?
Rod Pemberton
Rod Pemberton
"Betov" <be...@free.fr> wrote in message
news:XnF9A0F743A98...@212.27.60.39...
Didn't they need a volunteer to keep it upto date?...
I don't have a problem as long as the important info is somewhere. For WASM
(OpenWatcom), I usually use "asminsd.h", "asmins.h", and "insnspick.h" as
it's "Appendix A". And, for GAS (GNU), I usually use DJGPP's
"opcode/i386.h", and "tc-i386.h" as "Appendix A". They're not as nice, but
usually have the needed info somewhere. The main issue is syntax because
the instruction references are available online or from Intel or AMD. If I
can't find the syntax from them, I code a small NASM sample, compile for
either COFF or OBJ and then disassemble with OBJDUMP or WASM. OBJDUMP will
usually show a syntax that when assembled by GAS will generate the exact
byte sequence as the disassembled NASM instruction. However, this syntax is
usually different from what's in the GAS manual, but it's compatible and
accurate. Unfortunately, WASM won't. It will usually display a generic
form which may generate one encoding or an alternate. I.e., doesn't always
display needed keywords. There are still some unimportant sequences where
I'd prefer one form of an instruction, but can't figure out how to generate
it for WASM...
Rod Pemberton
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:fklrm5$9uq$1...@aioe.org...
>
> "Betov" <be...@free.fr> wrote in message
> news:XnF9A0F743A98...@212.27.60.39...
> > Charles Crayne <ccr...@crayne.org> écrivait
news:20071222182139.63063374
> > @thor.crayne.org:
> >
> > > The current NASM manual current does not have an instruction list, but
> > > the internal table has not changed.
> >
> > Why? Times ago i got an "AppendixA" from the NASM Documentation,
> > that had been reviewed by Debs, and which was rather clean. Why
> > was it removed?
> >
>
> Didn't they need a volunteer to keep it upto date?...
>
> I don't have a problem as long as the important info is somewhere. For
WASM
> (OpenWatcom), I usually use "asminsd.h", "asmins.h", and "insnspick.h" as
> it's "Appendix A". And, for GAS (GNU), I usually use DJGPP's
> "opcode/i386.h", and "tc-i386.h" as "Appendix A". They're not as nice,
but
> usually have the needed info somewhere. The main issue is syntax because
> the instruction references are available online or from Intel or AMD. If
I
> can't find the syntax from them, I code a small NASM sample, compile for
> either COFF or OBJ and then disassemble with OBJDUMP or WASM.
Correction: WDIS not WASM.
> OBJDUMP will
> usually show a syntax that when assembled by GAS will generate the exact
> byte sequence as the disassembled NASM instruction. However, this syntax
is
> usually different from what's in the GAS manual, but it's compatible and
> accurate. Unfortunately, WASM won't. It will usually display a generic
Correction: Unfortunately, WDIS won't.
> form which may generate one encoding or an alternate. I.e., doesn't
always
> display needed keywords. There are still some unimportant sequences where
> I'd prefer one form of an instruction, but can't figure out how to
generate
> it for WASM...
>
>
> Rod Pemberton
Rod Pemberton
Frank Kotler
> Charles Crayne <ccr...@crayne.org> écrivait news:20071222182139.63063374
> @thor.crayne.org:
>
>>The current NASM manual current does not have an instruction list, but
>>the internal table has not changed.
>
> Why? Times ago i got an "AppendixA" from the NASM Documentation,
Since April 30, 2002, "AppendixA" has been the (previously "lost")
Ndisasm documentation. At that time, the instruction set reference
became "AppendixB"...
> that had been reviewed by Debs,
Last check-in from Debs was June 2002 - five and a half years ago. It
seems like "only yesterday" to *me*, too... is it possible we're "behind
the times", mon ami?
> and which was rather clean. Why
> was it removed?
1) With the addition of 64-bit support, it became *badly* out-of-date.
2) Wasn't all *that* clean, despite Debs' excellent work.
3) No one has stepped forward to maintain that section of the document.
4) Not "about Nasm".
I think those are the reasons. I really *liked* having an instruction
set reference as a part of the Nasm manual, but I reluctantly agree with
the consensus of the development team that it "had to go". If a
maintainer steps forward to fix 1 and 2, I will use my influence (if
any) to have it re-included, despite 4. *I'm* not qualified to do it -
few *are*, and I think they're mostly busy.
You will notice, in the doc/ directory, the existance of "insref.src". I
haven't played with this, but I suspect it can be used to create a
free-standing instruction set reference... might need a little tweaking...
As a contribution to the somnolent "Luxasm" project, I created a
free-standing instruction set reference from the Nasm doc. I *thought*
I'd uploaded it to the Luxasm site, but when I lost my copy to the
partition mishap, I found that I had apparently not done so. Wasn't all
*that* much work, as I recall, but I've been too lazy to duplicate it.
My "future plans", at that time, were to create a "newbie's index" to a
few (which?) instructions, and possibly other indices besides the "full,
alphabetic" index in the old Nasm doc. I still feel this should be done
- not necessarily by me - but I'm not sure the Nasm reference is the
ideal starting point... not sure it *isn't*, either...
If you've ever installed Nasm *prior* to the removal of that section,
you've probably still got "nasmdocb.html" around somewhere - just no
longer a link to it in the table of contents... so it isn't a total loss...
Best,
Frank
Frank Kotler
...
> You will notice, in the doc/ directory, the existance of "insref.src". I
> haven't played with this, but I suspect it can be used to create a
> free-standing instruction set reference... might need a little tweaking...
Kinda like this:
http://mysite.verizon.net/fbkotler/nasmiref.zip
If folks find this useful, I'll dump it in the "contributions" section
on SF, or something...
Caution! The filenames conflict with filenames in the "main" manual, so
don't "overlap" 'em! "nasmdoc0.html" is the table of contents,
"nasmdoca.html" (again! :) is the main data, "nasmdoci.html" is the
index (not much different than TOC, but some...).
Best,
Frank
Frank Kotler
> Frank Kotler wrote:
>
> ...
> http://mysite.verizon.net/fbkotler/nasmiref.zip
>
> If folks find this useful, I'll dump it in the "contributions" section
> on SF, or something...
>
> Caution! The filenames conflict with filenames in the "main" manual, so
> don't "overlap" 'em! "nasmdoc0.html" is the table of contents,
> "nasmdoca.html" (again! :) is the main data, "nasmdoci.html" is the
> index (not much different than TOC, but some...).
Just replaced this with a version that also contains "nasmiref.txt" - a
plain ascii version, for those who prefer it. You want a Painful
Document Format version, create it yourself! :)
Best,
Frank
H. Peter Anvin
>
> You will notice, in the doc/ directory, the existance of "insref.src". I
> haven't played with this, but I suspect it can be used to create a
> free-standing instruction set reference... might need a little tweaking...
>
It's simply the frozen last copy of Appendix B.
-hpa
H. Peter Anvin
> Thank you.
>
> Wouldn't it be better to tag them by the required feature bit, not the
> potential instruction usage or cpu class?
No.
Right now the instruction group flags are handled a bit haphazard by
NASM, but the primary purpose of them are for NASM itself.
Instruction group selection isn't really implemented properly in NASM,
because it was originally implemented back when the x86 series was still
mostly a smooth progression, which is of course no longer the case.
That's on our todo list, but it's not all that high priority, partly
because it is a lot of work for relatively small benefit.
-hpa
Rod Pemberton
> Rod Pemberton wrote:
> > Thank you.
> >
> > Wouldn't it be better to tag them by the required feature bit, not the
> > potential instruction usage or cpu class?
>
> No.
>
> Right now the instruction group flags are handled a bit haphazard by
> NASM, but the primary purpose of them are for NASM itself.
>
Ah... So, the issue is how independent the documentation is from the
source. It seems that, courtesy of Frank, the two are separate now...
Rod Pemberton
H. Peter Anvin
Well, a lot of Appendix B was cut and paste from the source.
-hpa
Charles Crayne
"H. Peter Anvin" <h...@zytor.com> wrote:
> Well, a lot of Appendix B was cut and paste from the source.
Yes, and I have started playing with a perl script which will automate
the process.
-- Chuck
Evenbit
Argh! We should have yar hide { or have the doctors remove *your*
'appendix' } for suggesting that the "cp" command be written in
something other than ASM. ;-)
Nathan.
Robert Redelmeier
> Argh! We should have yar hide { or have the doctors remove *your*
> 'appendix' } for suggesting that the "cp" command be written in
> something other than ASM. ;-)
(Argh**Argh) `cp` _must_ be written in vanilla C for
portability between different systems. I would be appalled
if GNU fileutils `cp` contained a single line of ASM.
Besides, the C newbie's `cp` typically is 1000x _faster_ than
the ASM newbies. One of those hoary examples hauled out to
"prove" HLLs superiority.
ASM has a purpose, and 'cp' ain't it.
-- Robert
Charles Crayne
Evenbit <nbake...@charter.net> wrote:
> Argh! We should have yar hide { or have the doctors remove *your*
> 'appendix' } for suggesting that the "cp" command be written in
> something other than ASM. ;-)
Robert has interpreted your use of "cp" to mean the Linux copy command,
but, since there is no profit in rewriting system commands, I shall
assume that you meant some sort of esoteric cut & paste command.
However, that was not my intent at all. What I was actually talking
about was using a cross-platform scripting language as part of the
existing build tool chain so that no human would ever again have to
update the instruction list section of the NASM manual.
-- Chuck
Frank Kotler
Been done, anyway. Lemme see... my /bin/cp is 47608 bytes, the asmutils
cp is 742 bytes... C is approximately 64 times more productive!
(intellectual honesty compells me to admit that the asmutils cp has less
functionality... haven't tested speed)
Best,
Frank
santosh
I think it's safe to say that speed would be almost completely dependant
on the disk's throughput and the OS's buffering strategies than cp,
whether it's written in C, assembly or whatever. cp is a particularly
poor example to compare assembly with C. Something which is a bit more
processor intensive and a bit less I/O bound should be better, like
say, grep or gzip.
Evenbit
> In alt.lang.asm Evenbit <nbaker2...@charter.net> wrote in part:
You took me too literally when I was simply making a quick joke.
However, you make an interesting observation... although I think you
are mis-placing the blame. I think that "all" newbies {by definition}
will produce plenty of poor-performing code during their learning
experience. I think it is not until they learn more about the OS/
machine environment and focus on data structures & algorithms that
they begin to follow the right path.
Sure, high-level newbies typically have a head-start on producing
better-performing code -- but it is simply because they can rely on
the provided Standard Library and STL to do all the necessary generic
grunt-work for them. Eventually, if they venture into more
challenging applications, they will discover that an STL can be a
crutch that "gets in their way" in terms of performance.
Nathan.
Evenbit
Another thought that comes to my mind on this subject. If memory
serves me correctly, I think it was around version 6.00 that MS
introduced "xcopy" as a command into DOS to handle data-transfers that
the aged "copy" command was stumbling on. I cannot remember exactly
the cause, whether it was that "copy" was intrinsically supplied by
"command.com", or if it existed as "copy.com" ... but for whatever
reason, the standard copy command was SLOW {and this was noticable in
those days because floppy disks were still in routine use} because it
copied files in very small chuncks. I think "xcopy.exe" made use of
extended/expanded memory to copy entire files to memory before saving
them back to disk.
Nathan.
Evenbit
> On Sun, 23 Dec 2007 18:20:27 -0800 (PST)
>
Hmm... "cross-platform" you say? I am thinking of an "assembler" {if
we are still allowed to call it that} that bills itself as "cross-
platform" (amoung other things). :)
Nathan.
Charles Crayne
Evenbit <nbake...@charter.net> wrote:
> Hmm... "cross-platform" you say? I am thinking of an "assembler" {if
> we are still allowed to call it that} that bills itself as "cross-
> platform" (amoung other things). :)
NASM assembles code for two hardware architectures, and most of the
operating systems which run on them.
-- Chuck
Maxim S. Shatskih
> extended/expanded memory to copy entire files to memory before saving
> them back to disk.
This will not give you any speed, if the read/write size is >= hardware single
operation limit (64K on IDE).
Only multi-threading will give you speed on file copy.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Evenbit
> On Sun, 30 Dec 2007 14:07:12 -0800 (PST)
>
> > Hmm... "cross-platform" you say? I am thinking of an "assembler" {if
> > we are still allowed to call it that} that bills itself as "cross-
> > platform" (amoung other things). :)
>
> NASM assembles code for two hardware architectures, and most of the
> operating systems which run on them.
>
Okay, smarty pants! :) Let us see you provide us with *a single
source code* "Hello, World!" application which runs on those "two
hardware architectures" and a couple of those operating systems and
don't use anything which isn't available via the SourceForge download
station.
Nathan.
Evenbit
wrote:
> > copied files in very small chuncks. I think "xcopy.exe" made use of
> > extended/expanded memory to copy entire files to memory before saving
> > them back to disk.
>
> This will not give you any speed, if the read/write size is >= hardware single
> operation limit (64K on IDE).
>
> Only multi-threading will give you speed on file copy.
>
Well, with today's hardware, it does seem counter-intuitive, but at
the time that "xcopy" was introduced, the file on the drive could be
as big as about 1.4MB, so it was simply faster to copy the entire file
to memory before asking the user to switch floppy disks and saving to
the new one. Using the old "copy" method required the user to 'swap
the floppies' a dozen times to perform the same operation.
Nathan.
aku ankka
Hi Nathan,
The Netwide Assembler, or NASM, is a free Intel x86 assembler. It can
be used to write 16-bit, 32-bit (IA-32) and 64-bit (x86-64) programs.
32-bit programs can be written for NASM in such a way that they are
portable to all 32-bit x86 operating systems, if the right libraries
are present.
Frank Kotler
...
> Okay, smarty pants! :) Let us see you provide us with *a single
> source code* "Hello, World!" application which runs on those "two
> hardware architectures" and a couple of those operating systems and
> don't use anything which isn't available via the SourceForge download
> station.
Intellectual honesty compels me to admit that I didn't get the text
editor or ld from SoreFog. No idea whether the Linux64 or MacIntel ones
work - the 32 bit one does. No idea why we're calculating the string
length - Nasm would have counted it for us. No idea...
Best,
Frank
global _start
section .data
string1 db "Hello World!",10,0
section .text
_start:
%ifidn __OUTPUT_FORMAT__, elf64
; calculate the length of string
mov rdi, string1
mov rcx, -1
xor al,al
cld
repnz scasb
; place the length of the string in RDX
mov rdx, -2
sub rdx, rcx
; print the string using write() system call
mov rsi, string1
push 0x1
pop rax
mov rdi,rax
syscall
; exit from the application here
xor rdi,rdi
push 0x3c
pop rax
syscall
%elifidn __OUTPUT_FORMAT__, elf32
mov ecx, string1
; calculate the length of string
or edx, byte -1
.getlen:
cmp byte [ecx + edx + 1], 1
inc edx
jnc .getlen
; place the length of the string in EDX
nop
; print the string using write() system call
push byte 1
pop ebx
push byte 4
pop eax
int 80h
; exit from the application here
xor ebx, ebx
push byte 1
pop eax
int 80h
%elifidn __OUTPUT_FORMAT__, macho
; calculate the length of string
or eax, byte -1
getlen2:
cmp byte [string1 + eax + 1], 1
inc eax
jnc getlen2
; print the string using write() system call
push eax
push string1
push 1
mov eax, 4 ; __NR_write
call sys_call
; exit from the application here
push 0
mov eax, 1
call sys_call
sys_call:
int 80h
ret
%else
%error "Output Format (-f) must be elf32, elf64, or macho!"
%endif
Evenbit
It seems to me that "intellectual honesty" would compel you to admit
that what you have posted is actually the concatenation of three
seperate sources.
Nathan.
Frank Kotler
Do we clean up stack here??? This may be a "bug"...
>>
>> ; exit from the application here
>> push 0
>> mov eax, 1
>> call sys_call
>>
>>sys_call:
>> int 80h
>> ret
You're supposed to say "elifidn __OUTPUT_FORMAT__ win32 ..."!
>>%else
>>%error "Output Format (-f) must be elf32, elf64, or macho!"
>>%endif
>
>
> It seems to me that "intellectual honesty" would compel you to admit
> that what you have posted is actually the concatenation
"cut and past"
> of three
> seperate sources.
Count each instruction as a separate source? How many files do you see?
How many "hidden" files are included? If I put libc(s) in the
"contributions" section at SF and just called printf, would that satisfy
your conditions?
Best,
Frank
robert...@yahoo.com
> Another thought that comes to my mind on this subject. If memory
> serves me correctly, I think it was around version 6.00 that MS
> introduced "xcopy" as a command into DOS to handle data-transfers that
> the aged "copy" command was stumbling on. I cannot remember exactly
> the cause, whether it was that "copy" was intrinsically supplied by
> "command.com", or if it existed as "copy.com" ... but for whatever
> reason, the standard copy command was SLOW {and this was noticable in
> those days because floppy disks were still in routine use} because it
> copied files in very small chuncks. I think "xcopy.exe" made use of
> extended/expanded memory to copy entire files to memory before saving
> them back to disk.
Copy has always been a command.com (or cmd.exe) intrinsic function,
going back to PC-DOS 1.0. Xcopy dates to least DOS 3.2. If xcopy
made use of extended or expanded memory, it was not until later
versions. Anyway xcopy had several advantages, first being able to
make use of all (conventional) memory for copies, as well as being
able to use that memory for multiple files at one time. Copy was
limited to 64KB chunks, and one file at a time, so a diskette with
lots of small files would require many disk swaps. Note that neither
copy or xcopy actually directly supported swapping disks, but could
fake it with the OS support for treating A: and B: as different
logical drives, even on a system with a single physical diskette
drive.
Xcopy also has many additional options and functions that are not in
copy (subdirectories, for example). Copy, OTOH, could concatenate
files and handle character devices.
As to why xcopy was added instead of extending copy, I suspect there
were two reasons - copy had legacy syntax issues, plus there was a
desire not to expand command.com excessively.
Charles Crayne
Evenbit <nbake...@charter.net> wrote:
> don't use anything which isn't available via the SourceForge download
> station.
Your arbitrary requirement that assembly language programmers have to
obtain all their tools from a single vendor reminds me of something
that happened while I was working at a government sponsored research
lab. One of the researchers wanted to acquire a vacuum pump, but the
government required purchasing from the lowest bidder, and the
particular model the researcher wanted was not the cheapest.
After carefully reading the specifications of the various models,
he discovered that the one he wanted was 1/2 inch shorter than the
rest, so he wrote up the purchase request to specify that the unit must
fit under a shelf which was too low to clear the other units.
There was, of course, no such shelf . . .
-- Chuck
Charles Crayne
Frank Kotler <fbko...@verizon.net> wrote:
> Count each instruction as a separate source? How many files do you
> see? How many "hidden" files are included?
Your points are well taken, but nevertheless, you did give Nathan more
grounds for complaint than were necessary. Instead of cutting and
pasting three separate routines, you could have done like C does, and
obfuscate the differences in architecture by equating
(supposedly meaningful) names to the appropriate registers and kernel
call parameters.
For example:
%ifidn __OUTPUT_FORMAT__, elf64
%define pString rsi
%define __NR_write 1
%define __NR_exit 60
%define sys_call syscall
%else
%define pString esi
%define __NR_write 4
%define __NR_exit 1
%define sys_call int 80h
%endif
Then the body of the program becomes simply:
mov pString,String1
mov ecx,String1len
call sys_writeline
call sys_exit
-- Chuck
Rod Pemberton
"Charles Crayne" <ccr...@crayne.org> wrote in message
news:20080102221...@thor.crayne.org...
> %ifidn __OUTPUT_FORMAT__, elf64
> %define pString rsi
> %define __NR_write 1
> %define __NR_exit 60
> %define sys_call syscall
> %else
> %define pString esi
> %define __NR_write 4
> %define __NR_exit 1
> %define sys_call int 80h
> %endif
>
Why'd they switch to syscall for 64-bit? Also, did they change the value of
__NR_write from 4 for 32-bit to 1 for 64-bit? If so, that would mean that
the Linux API reordered from 32-bit to 64-bit... Does asmref show this?
(No...) *Why* would they do *that*? _Two_ API's to code for now on
non-Linux... Boneheaded... Linux... Programmers... Steamed...
Rod Pemberton
Charles Crayne
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote:
> Why'd they switch to syscall for 64-bit? Also, did they change the
> value of __NR_write from 4 for 32-bit to 1 for 64-bit? If so, that
> would mean that the Linux API reordered from 32-bit to 64-bit...
I can't speak as to why, but they did, indeed, reorder the kernel call
numbers, and change the registers used to pass the parameters.
x86_64 is truly a different architecture than i386.
-- Chuck
Scott Wood
> Why'd they switch to syscall for 64-bit?
Speed and the lack of 64-bit implementations that don't support it,
presumably.
> _Two_ API's to code for now on non-Linux...
> Boneheaded... Linux... Programmers... Steamed...
The API is C-based. The ABI is what changed.
-Scott
Rod Pemberton
"Scott Wood" <sc...@buserror.net> wrote in message
news:slrnfnq5ea...@thor.buserror.net...
Yes, you're right I don't make much distinction between the two. But, it
does depend on your perspective: C or assembly, and sphere of influence:
*nix or non-*nix. From assembly, the ABI is called directly without the HLL
wrappers, so the API is what changed... The concept of ABI vs. API is
really a HLL centric view. The code interface between the two for non-*nix
environments is quite sparse. They are frequently almost 1:1. Having seen
how DJGPP implements POSIX stuff, there is probably much larger code
interface between the two for *nixes - which allows the abstraction between
the two to be more pronounced and definable as separate concepts. Both
terms go back decades, but I don't recall ever seeing ABI used in the
non-*nix sphere until fairly recently... When I learned 6502 assembly, the
OS calls were called an API.
Rod Pemberton