News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Lingo on assembler code design

Started by lingo, March 14, 2007, 12:12:34 AM

Previous topic - Next topic

hutch--

Guys,

I have known Lingo for a long time and he is one of those people who has an acutely good understanding of the inner workings of high speed algorithms but that in itself is not a reason to be the critic of a whole host of other people in terms of their architecture. For anyone who has been around for a long time, architecture that is in any sense useful has a range of attrbutes that are the anti-thesis of obscure unreadable code.

For code to be even vaguely useful it must be very clear, well commented, reusable and flexible in its functionality yet here I am critical of Lingo's approach. For having written some brilliant optimisations in algorithms over a period of years, almost none of it survives as useful reusable code so most of the effort is lost. There are at least hundreds of members in this forum who have been writing assembler code since the bad old days when everything was unreadable, unmaintainable and not even vaguely reusable but the difference that raised assembler from the dead in the middle 90s when assembler programming was the laughing stock of the programming market was the combination of very clear code in reusable format and performance that left most of the rest behind.

Reverting back to the architecture of the past brings with it the effects of the past where assembler programming was ridiculed for being unlearnable, impractical and very slow to develop with but there is another factor that was alive and well back when assembler was the laughing stock of programming, the "gee whiz" approach, "ain't I profound, I can write code so complicated and unreadable that no-one else can understand it." The fruits of this approach were seen with the laughter that used to be associated with the mention of assembler programming.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

lingo

Hutch,
I'm just coming from work and I was surprised...
a lot of emotions here for nothing...

As a owner of this site and if you hate my code
so much just tell my great non-friend Vortex to delete it
and he will do that professionally with big pleasure  :lol

If I have more time I will continue our dispute
when I will be finished with my red black trees top-down
insert algo in assembly 

The world still use similar algo in "perfect" C/C++ and it is
"very clear, well commented, reusable and flexible in its functionality"
but more details soon...  :lol



Seb and E^cube,
I'm happy to see brave and honest people amongst you  :cheekygreen:
but please, don't worry so much because we were warned by Hutch
with: 
"The Laboratory"
"Post code here to be beaten to death to make it better,
smaller, faster or more powerful."
   :lol


Regards,
Lingo

hutch--

Lingo,

> a lot of emotions here for nothing...

Not exactly, when you make criticism you tend to get it in reply. If something is unacceptable, trust me in this much, I don't need to delegate its removal, I have been doing it for years but it tends to be stuff like porn sites, abuse and similar.

You are correct in reference to the Laboratory, the IS the place for advanced, difficult and obscure code but the Campus is NOT. You are neither the first and you will not be the last to have postings moved out of the Campus so you have not been discriminated against. Thats why the moved posting is here where it does not interfere with people who are learning the basics of assembler programming.

The idea of a red/black tree sounds interesting enough, I have occasionally played with tree design but not for a while as I find hash tables are generally faster. It will be interesting to see if your design is sensitive to insertion order in terms of how randomly the tree is constructed. I did play with a design that preferred a reverse sorted input but general balanced tree design seems to prefer highly random data in its input oder to produce maximum speed.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

lingo

"Not exactly, when you make criticism you tend to get it in reply."

The answer of the topic was:
"Should the pops occur before or after invoking ExitProcess?"

You and some people said "Before"  without any proofs
Lingo said "No pops"  and tried to prove his opinion
and I can't see criticism from Lingo to others here...
I saw the criticism and bad controlled emotions against Lingo about his opinion
As a free Canadian It was surprise for me and I can't let anyone  to make me
feel guilty for nothing ...

u

Quote from: hutch-- on March 16, 2007, 03:51:22 AM
when you make criticism you tend to get it in reply.

Yes, and that's why Lingo replied to PBrennick's "When we are trying to teach good coding habits there is always some ----- who comes along and, well you know."

He also provided the info [that really must be made one of the first things to teach in asm tutorials, but it isn't ] about why and where ebx/esi/edi should be preserved: in callbacks (because WinAPI uses them for enumeration). There's no environment-info stored in those regs, it's just that the C compiler Microsoft uses has been implemented with that in mind.

Even a C compiler won't have the stack balanced and ebx/esi/edi popped before ExitProcess() - the compiler pops them after the call, before the current proc's return - which is something never to be executed.

So actually why ebx/esi/edi rules came from win2k/2k3s/xp/vista, but weren't present in win98 and before? Because Microsoft's C compiler's optimization was bad - storing and restoring registers to/from the stack almost always. So, enumeration didn't use those 3 registers accross calls.

Draakie pointed-out what good coding habits basically are, and that should have been the last post in this thread.
Yet, to add: you need knowledge and experience to know why and where these habits have to be applied. And making these habits more strict is up to the coder's judgement in the project environment. Since Lingo has knowledge and experience, he directly pointed to the answer. Sure, in the code he posts here he doesn't put comments - but mind you that it's probably (I'd say "definitely") something he composed in a few minutes after seeing a request on this board - and since the code isn't 5000 lines, commenting isn't necessary. Why not necessary? Someone who isn't good at asm, and doesn't care, won't read comments anyway. Someone who isn't good at asm yet, but wants to learn, will try hard to think and understand - eventually reading a few references and articles in parallel to studying the code - isn't this a good for one's brain? One who is good at asm and wants to understand how the code works - will simply trace it in one's mind, see if all possible cases are covered via the code, convert the code to his style, and possibly write comments in his own style.
Again, Lingo doesn't post 5000 lines at once - so you really can't judge what his coding habits actually are. And blaming him for indirectly making nuggets/us try to think hard, isn't very valid imho.

My 2 cents.
Please use a smaller graphic in your signature.

hutch--

Let me clear up a number of misconceptions, the OS register preservation rules for 32 bit PE version of Windows was in place in Windows NT 3.5, the specification is even earlier and originates from Intel. In EVERY 32 bit version of Windows the same rules apply. It just happened to be that some win9x versions did a bit of additional hand holding to prevent incorrectly written code from crashing.

I have had people stand up and argue about this set of specifications for many years but the same set of people do not help out when a person learning assembler writes an app that breaks the register preservation rules and crashes for reasons that they don't understand. While it is simple for experienced programmers to see an unprotected use of any of the 5 registers that must be returned with the same value to the OS, it is no joy for a person learning assembler to try and find it if they have been fed bullsh*t about register preservation rules.

Teaching good habits is critical to people learning a complex area of programming like assembler as there is a high failure rate when people attempting to learn this area keep getting code that crashes and they don't know how to fix it. This does not matter to people who are more interested in flaunting how complicated their own code is than actually getting more people to succeed in writing code that works.

Now anyone who has been around for a while already knows that the ExitProcess() API call does not return so it simply does not matter what state you leave the stack or what value you place in system specified registers.


invoke ExitProcess, arg etc ...

    ret

Whatever_proc endp


In MASM this translates to something like,


push 0
call ExitProcess
leave
retn [bytecount]


The LEAVE and RETN instructions are never executed because the OS terminates the thread when the ExitProcess() API function is called.

Does this mean you set a general rule to mislead learner programmers so that their code crashes and the don't know why ? I suggest not, if people learn good habits that produce reliable code, they can then lean all of their own bad habits later on the basis of knowledge of exceptions.

Now this translates to the Campus NOT being the place for debate on these issues, freestyle architecture, deviant techniques and the like all have their place but its not in the Campus. The rule was put in place when the forum was started to exactly address this problem of confusing learners with arguments.

Now in particular to some of Lingo's comments,
Quote
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

Strangely enough those of us who owned MMX boxes in 1996, SSE boxes before 2000, SSE2 boxes shortly after and SSE3 boxes when they became available didn't miss the bus. Boasting wih elitist assumptions does not wash with people who have been writing code since before 1990.

Quote
"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

Having had Intel PDF manuals since they started producing them as technical reference for x86 hardware and having produced the Winhelp version of Agner Fogs earlier optimisation manual, its not as if name dropping on reference material proves any point here, we have all had this stuff for years. Anyone claiming to be te "correct interpreter" of the reference material is patting their own back and making elitist assumptions.

None of these things worry me as I have been the target of criticism for years but I am equally capable of making it in return and in this case I have been willing to do so at the level of producing unreadable obscure code that is rarely ever re-usable. I have made the point before that people who can read it don't need it and those who most need it cannot read it. Any notion that code this bad is delivered as some form of teaching aid to people who have been writing fast reliable code for years is simply more ego massaging with elitist assumptions.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php