Lingo on assembler code design

[lingo]

"So, there's no need for this, either?"

YES, no need for this... :lol
But I wondering why you need to preserve registries esi,edi and ebx
in your main proc... :wink

If you don't care about ExitCode
(you don't plan to use GetExitCodeProcess API)
you can just write:
jmp ExitProcess
rather than 
INVOKE ExitProcess, ExitCode

You can see my similar example too:
http://www.masm32.com/board/index.php?topic=6729.0

Regards,
Lingo

Later:
Many years ago in high level languages
we learned how to create "good practice" code
and "good coding habits"
For example: Never use GOTO and blal-bla bla... :lol

Today the times and CPU's are different
We learn how to create good code from the
Intel&AMD Optimization manuals; from the book of the A.Fog too.. 

There are always people ----- who missed the bus
so, don't allow them to try to manipulate your mind
and always ask them for proofs and their code :lol

[hutch--]

 :lol

Yes but there has always been people who wrote unreadable unreliable code that was unmaintainable in areas where there was no performance gain by writing it in such an obscure manner and thus you have the "world's fastest MessageBoxA" mentaility complete with all the fanfare of a gnat breaking wind. Code obscurity has its place but only when the target audience is NOT supposed to understand the code being written.

The decisive factor in resurrecting assembler from the dead 10 years ago was to put aside the trivial and put your effort into code that mattered, primarily speed critical algorithm design where you actually get something back for your effort. The alternative so often sprouted back then as the "right way" to write assembler code nearly put assembler programming in its grave.

[hutch--]

I had just a little time to waste this afternoon so here is a 1k windows coded the old way, something like the code style of 1990. No equates, mindless label names, no commenting and a particularly irritating technique that you would call stack forwarding where the arguments for procedure calles are nested to get some of the procedure calls sequential.

Contrast this disaster to the masm1k example in the masm32 example code and you will see that its no smaller, no faster and has no additional functionality but its sure badly written, unreadable, unextendable and unmaintainable.

Code Select Expand


.686p
.model flat, stdcall
option casemap :none
externdef _imp__DispatchMessageA@4:PTR pr1
m2wp equ <_imp__DispatchMessageA@4>
externdef _imp__GetMessageA@16:PTR pr4
gms equ <_imp__GetMessageA@16>
externdef _imp__DefWindowProcA@16:PTR pr4
dpro equ <_imp__DefWindowProcA@16>
externdef _imp__PostQuitMessage@4:PTR pr1
pqm equ <_imp__PostQuitMessage@4>
externdef _imp__RegisterClassExA@4:PTR pr1
scln equ <_imp__RegisterClassExA@4>
externdef _imp__ShowWindow@8:PTR pr2
wshw equ <_imp__ShowWindow@8>
externdef _imp__LoadCursorA@8:PTR pr2
lsc equ <_imp__LoadCursorA@8>
externdef _imp__CreateWindowExA@48:PTR pr12
crwe equ <_imp__CreateWindowExA@48>
includelib \masm32\lib\user32.lib
.code
ims db "Slick Huh ?", 0
pcl dd ims
slick_huh:
push ebp
mov ebp, esp
sub esp, 96
push 32512
xor edi, edi
push edi
mov esi, 4194304
mov ebx, pcl
call lsc
mov DWORD PTR [ebp-96], 48
mov DWORD PTR [ebp-92], 3
mov DWORD PTR [ebp-88], OFFSET wpep
mov DWORD PTR [ebp-84], edi
mov DWORD PTR [ebp-80], edi
mov DWORD PTR [ebp-76], esi
mov DWORD PTR [ebp-72], edi
mov DWORD PTR [ebp-68], eax
mov DWORD PTR [ebp-64], 10h
mov DWORD PTR [ebp-60], edi
mov DWORD PTR [ebp-56], ebx
mov DWORD PTR [ebp-52], edi
lea eax, [ebp-96]
push eax
call scln
mov ecx, -2147483648
push 1
push edi
push esi
push edi
push edi
push edi
push ecx
push edi
push ecx
push 13565952
push ebx
push ebx
push edi
call crwe
push eax
call wshw
lea ebx, [ebp-48]
push edi
push edi
push edi
push ebx
jmp mlep
@@: push edi
push edi
push edi
push ebx
push ebx
call m2wp
mlep: call gms
test al, al
jnz @B
leave
retn
wpep: cmp DWORD PTR [esp+8], 2
jne @F
push 0
call pqm
@@: jmp dpro
end slick_huh

[attachment deleted by admin]

[TNick]

As always, it is very intreresting to read a debate between such experimented coders. I think I can tell that I understand all opionions and there is only one conclusion: "The power is yours", as Capitan Planet was saing in a cartoon from my childhood. :):)

Nick

[lingo]

Hutch,

"...unreadable unreliable code..."

I'm very sorry that my code is
"unreadable" for you but I wondering
how you know that it is "unreliable"
when you are unable to understand it?  :lol

I'm not guilty that people who understand
my "unreadable" code as bitRake,
The Svin, Nexo, Mirno,etc don't visit
your site 


Nick,

To argue against someone who doesn't
understand my code is "causa perduta"
and I can repeat:
"We learn how to create good code from the
Intel&AMD Optimization manuals; from the book of the A.Fog too.."
rather than from Hutch or from his administrators..   :lol

I appreciate their efforts to help new people to start coding in assembly
but this is C like (easy) assembly code rather than "a good assembly code"

Regards,
Lingo

[hutch--]

The problem here of course is that the architecture of Windows IS C code which is very easy to emulate in assembler. If it was pascal or Fortran or basic, it would be just as easy to emulate if you were familiar with both. Where the difference lies is between hack OS code that has C architecture and algorithm design that has any architecture you wish to use. I would rathere spend the time writing algorithms than the world's fastest MessageBoxA as you get something useful for the effort.

My generation grew up both reading and writing code written like assembler dumps so its not like its a big deal

"We learn how to create good code from the
Intel&AMD Optimization manuals; from the book of the A.Fog too.."
rather than from Hutch or from his administrators.

This may be useful but nothing improves on the clock, optimisation manuals are a reasonable guideline but no matter how "approved" the technique is, if it does not clock faster than other reference code, its a waste of time.

An optimisation manual will never tell you what is worth the effort and what is not, you can use a profiler if you need it but if you have written code long enough, you don't waste the time on the world's fastest MessageBoxA, you put it into time critical algorithm design.

The problem as I see it with elitist code design is that the people who can read it don't need it and the people who most need it can't read it. Any of the old fellas can write complicated unreadable code, that how it was done 15 years ago but the style of code that brought assembler back from the dead was partially structured and highly readable.

[lingo]

"The problem here of course is that the architecture of Windows IS C code which is very easy to emulate in assembler. If it was pascal or Fortran or basic, it would be just as easy to emulate if you were familiar with both."

This is just bla, bla, blah for my CPU
because it understands just machine (assembly) code. :lol


"..with elitist code design is that the people who can read it don't need it ..."

Absolutely Wrong!
Such kind of code is a pleasure for them and valuable source to "crib" some new idea
and this makes the "art of assembly" rather than R.Hyde HLA... :lol
If you meet somewhere  bitRake, The Svin or Nexo ask them about that... :lol

Example:
Everyone starts to play piano or violin with the hope one day to become one of the
world's elite musicians rather than to play in the church just on Sunday
again and again the same music forever...   


"...and the people who most need it can't read it.

Hence, they must continue to learn assembly outside of your non "elitist"
site, from other sources (sites), for instance: A.Fog site or INtel@AMD sites
with a lot of "unreadable" assembly code and there is no church  musician
to tell them "My music is easy "readable" and "reliable"... :lol

[uziq]

Wow, I had no idea my question was so complicated.  :lol

and, I happen to enjoy my blazingly-fast msgbox. Thank you very much. :bg  (You gotta start somewhere.)

[PBrennick]

I think Lingo needs to start his own forum. He IS a good programmer. It is just that this stuff has no business in the Campus (or GeneSys).

Paul

[ecube]

I personally think lingo is one of ,if not the best ASM programmer active on this forum and in public ingeneral. I look forward to reading anything he posts   :U

[hutch--]

 :bg

This is just bla, bla, blah for my CPU
because it understands just machine (assembly) code

You must have a very unique CPU then, my PIVs just run normal x86 instructions up to SSE3. Now it would be fine if you were writing applications to your own OS but this is not the case, when you write Windows code and need to interact with the OS you either comply with its specifications or your code breaks. Its like your local church playing "Rock of Ages" every morning, you may hate it but thats the way it is.

It would not matter if you preferred Windows to have a Fortran architecture, Cobol, Forth, basic or even the 16 bit DOS assembler architecture in command.com and the DOS and BIOS interrupts, Windows has a C architecture of things like zero terminated strings, pointers, unions, structures and is both designed and specified in C, not anything else.

Where you don't have this limitation is when you write your own code that is not API dependent, with an assembler you have full architecture control and can put anything you like together if you can get it to work so its not as if you have any real limitations on what you write yourself.

Now I will make the point again with interfacing with the OS you place whatever the specified arguments require onto the stack and call an address in a system DLL and from there until the API returns you have NO CONTROL AT ALL at what it does. Apart from old tricks like copying an API into local application memory, there is no such thing as an optimised API call.

Highly optimised code is often hard to read but at least you get something for your effort in time critical operations but writing API code in the same manner gives no performance improvement but highly reduced access due to understandability. It is counter productive to make code so obscure that few can read it let alone understand it and use the ideas.

[PBrennick]

And just to add my two cents, anyone who codes that way is not a professional and is just playing with assembly as a gimmick so they can say, 'see what I did?' Then they wait greedily for the hero worship. Do that in a Corporation and you will find yourself out of a job very quickly. No one is going to allow someone to write unmaintainable code, what happens if you get sick or die. And if you say, "I have the right way. Everyone needs to learn my way." Take a guess what will happen?

Optimization was extremely necessary in the old days when memory and space was at a premium. Now, it is only used in critical situations or by hobbyists to test their skill and have fun. And I have seen some members, here, who are VERY skilled at optimization and their code IS readable!

Paul

[Draakie]

Sorta have to agree with Hutch and PBrennick on this matter - maintainability and readability is everything when
working on larger assembler projects. As for lingo's skill in what I've seen of his code - "well - erm - that's nice "
and that's about it then. Why make your life a living hell just to try and save 5 cycles on an API call !? Use your
FANTASTICAL OPTIMIZATION & OLD SCHOOL CODE skills WHERE THEY MATTER and comment it to DEATH.
That to my mind is the mark of an UBER Assembler coder. The rest sounds like Propeganda and unfit for serious debate.

Thanx
Draakie

[/Edit] UBER = German for GREAT //  Oops - I thought every-one knew that  //  So much for Commenting on Comments [/Edit]

[ramguru]

Draakie, you are no better than lingo,
lingo writes unreadable code, and you - unreadable reply  :P

That to my mind is the mark of an UBER Assembler coder.

[daydreamer]

sorry, almost all asmcode went down in performance 50% on newest multicores, because clock freq went down and everyone still is stuck in old thinking programming singlethreaded
sorry, all your asmcode has no hope to perform 6 times faster because you shave a cycle here and there on scalar code and dont intend to learn this skill because of prejudice its not worth learn SSE/SSE2
sorry, most asmcode is tricks with only use general regs, but not seen much optimization tricks on fpu , when every game does transforms etc on fp's and fpu isnt too slow compared to integer anymore, fpu also can do several things in parallel, if you issue operations to right ports etc

once upon a time, in ancient times, 8087 was the only fpu and few had it equipped and it was dead slow, so we always coded with cpu instead(was it 1980's?)
what are you doing still sticking to general regs year 2007??? :naughty:
:toothy