Re: Is PSHUFW instruction MMX or SSE or SSE2? Is NASM manual correct?

På Tue, 25 Dec 2007 12:45:43 +0100, skrev santosh <santosh.k83@xxxxxxxxx>:

//\\\\o//\\\\annabee wrote:

På Tue, 25 Dec 2007 07:04:47 +0100, skrev santosh

<snip>

Hi santosh.

Most code written by asm newb will blow away anything a c newb could
write. (save maybe for a trivial empty loop)

Perhaps. I don't have enough data to judge. Anyway this seems to be an
intrinsically individual problem.

Given two comparable "individ"s, then the one with the better access to facts will do better research. Better light, better sight, bigger chance of not falling. This is undenyable.

Compilers for the x86 are pretty damn good nowadays. I doubt that a
newbie C code is going to underperform a newbie assembler provided you
are comparing the _same_ algorithm.

Yes.. as long as we will compare "apples with apples": that is, if the newb C programmer calls to std:sort (?) todo a binarysort, and the asm coder is writing the Quicksort himself, this is not what I mean. The newb C programmer must _also_ write his quicksort himself, using C. If the two have otherwise the same preconditions, then the asm coder will both grok it faster, write it faster, debug it faster, and have a much faster first working sort routine. Thats is what I ment.

The best programmers know both assembler and HLLs and use whichever is
appropriate for the task at hand.

That sounds to me like a trap. Whats the definition of a "best programmer"? Do you not define it in the sentance itself? Trying to sneak it past me now that I am tired ? :D They are best because they use the "appropriate tools...." therefore "the best programmer know both...." .. :D

Theese guys are just Trolling Santosh, trying to revive a topic thats
been dead since ages, dead, because it got burried, by a C convention
commite, a bunch of dishonest fools who we had better erase from the
face of the earth.

Well, if not for C (or some other HLL), we probably wouldn't have the
pervasive computing that we now take for granted. The cost of a
software rewrite would have either made computers prohibitively
expensive or stifled the explosive growth of software that we have been
seeing for the past two-and-a-half decades.

Could as well be because so many people worked with those tools. btw, before RosAsm, there never really existed a good tool for doing large scale app devs in asm.

Yes die-hard technical users would still manage to use computers and
even thrive, but it would never have become the mass phenomenon that it
has.

The very best apps (userside) was created by asmers in the past.

Tell me Wannabee, how many people use your software? Instead of
exploring around in assembler (which I agree is good), you had instead
used something like C++ or Java you'd probably have a huge amount of
working code by now that a lot of people may perhaps use. Sure, it
might not be as impressive as the assembler version, but who cares
about a few thousand cycles and a few Mb of RAM nowadays, do we? :-)

I am not focusing on creating apps now, because I am working on the foundation for the apps I will create in the future. The "apps" I create now are nothing but testcases for the GUI I am coding. btw, here is the very last piece of code I wrote. (posted at the bottom of this post). It is nonrecursive code for searching a hardrive for a file. It does not cache the files, and thus needs no extra memory. Full explaination of the code is provided at the top.
And some comments also in the code itself.

Instead you are still to do your GUI and the only code I have seen of
you recently is HLAFucker. :-)

Would you belive me If I told you the time it took to write the first one, was spent allmost entirely at the drawing? And that I rewrote it from 2mega to 16k in one hour? using of cource RosAsm, because it would have not been possible without it.
I am a pretty mediocre programmer. Think what a true genious could do with it. RosAsm cannot be overestimated, it is 100 times the tool that any coder could possibly be able to dream he could have.

Of course I don't even have that much to
show, so I'll shut up now. I'm not attacking you personally, just
pointing out that an HLL may perhaps have helped here.

I found you allways to be a breeth of fresh air to this ng. I dont perceive critic as attack. Critic is only of good, imo. Educated critism is best :D

If programming were just an art, machine code and assembler would still
rule the roost, but it's (fortunately or unfortunately) more of a
business than an art.

It started out as a joke, then it became art. And once it was becomming POPULAR, moneymakers started showing interesst. Internet was practically built by entusiasts, for free (content) and there was for instance free email apps, for windows, like for instance Pegasus mail, allready in '93 that wore WAY better at that time, then any commersial app since. At that time I was corrsponding with its OZ writer, asking questions about windows programming, and he answered two minutes later, very polite, very forthcomming. It was a diffrent world and so much nicer before the corporate morons, lawers and etc joined the game. Since then, I have seen reruns of the past, mostly, until I found RosAsm, the only real news in programming since Delphi 1.0

All those commersials apps wore created directly from ideas spawned by entusiasts. Then of course, before windows, there was Unix. (also mac/amiga) Everything we have today, except for the latest flashiest games, was allready there 20 years ago, or more. Even most if not all the technology we have today, was thought out allmost 100 years ago, and in some cases even 300 years or 2000 years ago. Even many graphical algoritms was created 60-70 years ago, that are just now beeing used in games. So dont come and tell me, that C or any HLL have added anything to this world. They have not. They have crippled it.
And buisness have absolutly NADA todo with the development of the ideas. They make money from the ideas, and nowadays they steal them, legally, and then they burn the people that are responsible for their wealth. Dont you buy the web 2.0 hype, its a fad. Did you not read the "Free lunch" is over from 2004?

Assembly will come back. This is now a very safe bet, since machines are no more getting significantly faster. Do yourself a favor and jump on the train while there is still some funky seats available. ESPESIALLY if you want to earn you living from coding, you gotta get good at asm now!

In business it's speed of delivery, features,
hype and money that matter.

For now. But we are still at the very stoneage of the computer evolution.

A hand crafted gem that no one buys is
worth less (from a "merchants" point of view) than a poor imitation
that nevertheless sells like hot cakes.

In the "near" future unless you know asm, you will not be able to find work...

If programming had been pure science instead of art or business, still
HLLs would have been developed since artificial language theory is a
fascinating area.

Thats is because you dont let yourself have access to a good assembler.
I can recreate allmost any artificial language in asm, and I did this a few times allready, and asm is .. and espesially RosAsm is _the_ current tool for such experiments.

But they might not have been used as ubiquitously as
they have been, if the impetus of money was not there.

Tell you what, if you are up to it, lets do a routine to convert an
hexadecimal string (without '0x' prefix or 'h' suffix) into the
corresponding 64 bit numerical value. You do yours in assembler and
I'll do mine in C and lets compare the relative speed for a few million
passes over the test string.

You are on. But I will have to sleep soon, so for tomorrow.
But it will only be for comparing apples to apples. You do not call a lib, you write it in "pure" c ? ok?

We can use C's clock() function or RDTSC,
whichever you prefer. Respond if you are up to it and I'll post my
version's source and test run on my machine.

I prefer RDTSC. Because I failed to time code once, using windows performance counters. I do not know what C's "clock" is, but if its the performance counters in windows, they are badly miswritten. They claimed a 2000 cycles FPU instruction series to take like 5 clocks.

Now I must sleep. Tomorrow I start writing the 64bit hex to decimal(?) routine. Below I have posted the routine I promised at the top. Bye for now.




;;
performs a scan of the harddrive, without caching all the
memory like [oFileCreate] and [oFileScanHardDrive] does
It also does not use recursion, but push the current directory
state on the stack, before searching subdirectories.

It works like this:

Pass the path to search, say (example) "C:\" in "Path"
pass a pointer to at least 256 bytes in "WorkPath"
pass a pointer to a callback procedure in "CallMe"
(That is called for each file found)
and finally a callback to the procedure to call for a file that
is "accepted" in @OnFileAccepted


DESCRIPTION:
The very first thing we do is to push the marker "DEAD_BAAD" to stack

Second, we add "\*.*" to "C:\"

Now we can use the APIFindFirstFile to open a searchhandle for this directory.
If we opened a searchhandle successfully, we push that handle to stack,
and then we push the WorkPathIndex:

"C:\*.*
| |
| |
| WorkPathIndex
|
WorkPath :

We now search the C:\ directory..........

Say that we find a directory in C:\ that is called DOS
We can now use the WorkPathIndex to construct a new subdirectory.
We append DOS to WorkPath, beginning from WorkPathIndex.
"C:\DOS" .. we add the "\*.* (needed for the OS searchpath) and end up with

"C:\DOS\*.*"

This forms a new directory searchstring.
We again open it using APIFindFirstFile

Also again we push the _handle_ for the path C:\DOS (save it away)
and then we push the WorkPathIndex pointer "C:\DOS\ |<now pointing here| *.*"
(Save it away too = maybe come back later)

"C:\DOS\*.*"
| |
| |
| | WorkPathIndex
|
WorkPath

We now search this directory. If no sub directories are found in "C:\DOS\*.*"
then we must go UP one directory.
First then, we CLOSE the searchhandle for "C:\DOS", and since its on the stack,
we pop it, and then close it, and then we clean up the stack by poping the
WorkPathIndex that is then not used anymore.

Now we continue and pop again the searchhandle for the _previous_ dir, which will
be the handle for "C:\", and we also pop the WorkPathIndex for that, and that
resets the state of the search to the "C:\" dir. The searchhandle remeber its previous
state, and we can call APIFindNextFile on it, to get the file AFTER the previous
C:\DOS finding, earlier on.

We also RE- pusj both the handle and the WorkPathIndex, a second time, to fully
reset the state before we went into the \DOS directory.

We continue this task, until we pop a "searchhandle" that equals our marker
"DEAD_BAAD" that we pushed at the very beginning
;;

Proc FileSearchDirectoryUncached:
Arguments @Path @WorkPath @CallMe @OnFileAccepted
Local @WorkPathIndex @NumStatesOnStack
mov D@NumStatesOnStack 0
mov eax D@WorkPath
mov edx D@Path

While b$edx <> 0 | mov cl b$edx | mov b$eax cl | inc eax | inc edx | End_While
cmp b$eax-1 '\' | jne L0>
dec eax
L0:
mov d$eax '\*.*'

mov D@WorkPathIndex eax

;;
push our marker that when popped signal the end of the search
;;
push 0_DEAD_BAAD

L0:
mov eax D@WorkPath
APIFindFirstFile eax WIN32_FIND_DATA

.if eax <> &INVALID_HANDLE_VALUE
push D@WorkPathIndex
push eax
inc D@NumStatesOnStack

L1:
ifFlagSet D$dwFileAttributes &FILE_ATTRIBUTE_DIRECTORY

;;
Skip the "." and ".." directories because we dont want to search again
the currentdir "." and the previous dir ".."
(it would also cause a never ending loop)
;;
cmp b$cFileName '.' | je L2>>

;;
append the new directory found, plus the "\*.*" search criteria (all files)
and jump back to search the new path.
;;
mov eax D@WorkPathIndex | inc eax | mov edx cFileName
While b$edx <> 0 | mov cl b$edx | mov b$eax cl
inc edx | inc eax
End_While

mov d$eax '\*.*' | mov b$eax+4 0
mov D@WorkPathIndex eax
jmp L0<

ElseIfFlagCleared
;;
comming here, means that we found a FILE and not a directory
so we call the "CallME" callback to signal this.
CallME should return EAX = TRUE if it wants the file.
If it returns TRUE, we contruct the full filename in
TempFileNameBuffer and point edx to that buffer and call

D@OnFileAccepted //set by the caller when calling this proc
if Carry is set after that call returned, we continue
the search, else the search is over "Accepted"

If the search is over, we clean up the stack, by poping everything
there until we receive our marker.
By recording the number of pushes, we can speed up this
by just adding to ESP.
;;
call D@CallMe


if eax = &TRUE
mov eax D@WorkPathIndex |
inc eax
mov edx cFileName
While b$edx <> 0 | mov cl b$edx | mov b$eax cl |
inc edx | inc eax | End_While
mov b$eax 0

ZeroMemory TempFileNameBuffer &MAXPATH

mov eax D@WorkPath
mov edx TempFileNameBuffer
while b$eax <> 0 | mov cl b$eax |
mov b$edx cl | inc eax | inc edx | End_while

mov edx TempFileNameBuffer
UserCallBack D@OnFileAccepted
jc L6>
L5:
shl D@NumStatesOnStack 1
add esp D@NumStatesOnStack
mov eax &TRUE
jmp L5>
end_if
L6:
EndIfFlagSet
L2:
mov eax D$esp
cmp eax 0_DEAD_BAAD | je L4>
L3:
mov ebx eax
APIFindNextFile eax WIN32_FIND_DATA
or eax eax | je L8>
cmp b$cFileName '.' | jne L9>
mov eax ebx
jmp L3<
L9:
jmp L1<<
L8:
APIFindClose ebx
add esp 8 ;done with this folder.
dec D@NumStatesOnStack
mov eax D$esp
cmp eax 0_DEAD_BAAD | je L4>
mov ebx D$esp+4 | mov D@WorkPathIndex ebx
jmp L3<
.Else
mov eax D$esp
cmp eax 0_DEAD_BAAD | je L4>
add esp 4
pop D@WorkPathIndex
dec D@NumStatesOnStack

jmp L3<
.End_if
L4:
add esp 4
xor eax eax
ExitP
L5:
EndP



--
.

Quantcast