Hi again Thomas:

Just a quick note about something you mentioned earlier...


Well if you would translate it directly in MASM code it would still test x for 1 twice and add useless jumps to the next instruction that will never execute.


It seems my generated code is different than yours.
Two tests for 1, yes. Useless jumps, no...



179: .if ecx == 1

00401DA8 83 F9 01 cmp ecx,1
00401DAB 75 04 jne @C000A (00401db1)

180: return 0

00401DAD 33 C0 xor eax,eax
00401DAF C9 leave
00401DB0 C3 ret

181: .endif
182: .if ecx > 1 && ecx < 16

00401DB1 83 F9 01 cmp ecx,1
00401DB4 76 0A jbe @C000C (00401dc0)
00401DB6 83 F9 10 cmp ecx,10h
00401DB9 73 05 jae @C000C (00401dc0)

183: return 1

00401DBB 33 C0 xor eax,eax
00401DBD 40 inc eax
00401DBE C9 leave
00401DBF C3 ret

184: .endif
185: return 2

00401DC0 33 C0 xor eax,eax
00401DC2 40 inc eax
00401DC3 40 inc eax
00401DC4 C9 leave
00401DC5 C3 ret


The duplicated test didn't bother me, but I was a bit concerned about the phantom jumps. But I don't see them here.

So, just for fun, I tried using .elseif's, and lo & behold, it generated the exact same code...!



179: .if ecx == 1

00401DA8 83 F9 01 cmp ecx,1
00401DAB 75 04 jne @C000A (00401db1)

180: return 0

00401DAD 33 C0 xor eax,eax
00401DAF C9 leave
00401DB0 C3 ret

181: .elseif ecx > 1 && ecx < 16
182: return 1

00401DB1 83 F9 01 cmp ecx,1
00401DB4 76 0A jbe @C000C (00401dc0)
00401DB6 83 F9 10 cmp ecx,10h
00401DB9 73 05 jae @C000C (00401dc0)

183: .else

00401DBB 33 C0 xor eax,eax
00401DBD 40 inc eax
00401DBE C9 leave
00401DBF C3 ret

184: return 2
185: .endif

00401DC0 33 C0 xor eax,eax
00401DC2 40 inc eax
00401DC3 40 inc eax
00401DC4 C9 leave
00401DC5 C3 ret


No phantom jumps!

The above output is from MS Visual Studio's disassembly window, so just to be sure, I used OllyDbg. Same thing, as expected:



00401DA8 |. 83F9 01 cmp ecx, 1
00401DAB |. 75 04 jnz short 00401DB1
00401DAD |. 33C0 xor eax, eax
00401DAF |. C9 leave
00401DB0 |. C3 retn
00401DB1 |> 83F9 01 cmp ecx, 1
00401DB4 |. 76 0A jbe short 00401DC0
00401DB6 |. 83F9 10 cmp ecx, 10
00401DB9 |. 73 05 jnb short 00401DC0
00401DBB |. 33C0 xor eax, eax
00401DBD |. 40 inc eax
00401DBE |. C9 leave
00401DBF |. C3 retn
00401DC0 |> 33C0 xor eax, eax
00401DC2 |. 40 inc eax
00401DC3 |. 40 inc eax
00401DC4 |. C9 leave
00401DC5 \. C3 retn


(I'm using MASM Version 6.14.8444)

:confused: :grin:
Posted on 2003-03-30 17:53:49 by MANT
Originally posted by MANT
The duplicated test didn't bother me, but I was a bit concerned about the phantom jumps. But I don't see them here.

You're right, I was wrong.. it is only with elseifs (*see below)

So, just for fun, I tried using .elseif's, and lo & behold, it generated the exact same code...!
No phantom jumps!

From the leave's in your code I see you were using the proc statement. I didn't :). In procs, the 'ret' opcode is actually a macro so probably MASM will now know the proc will end and never fall through the .IF construct.
My examples were just plain code (no procs), that's probably the reason I got the jumps and you didn't :).

So as long as you use them in PROCs no jumps should be generated.. that's nice at least:).

Thomas
Posted on 2003-03-31 02:53:02 by Thomas
There are a a couple of things that I would comment on here, the major advantage of a language like C++ is still its portability, without that, you lose to the overhead of stuff like rigid type casting where you only have 2 possibilities, signed or unsigned.

If there is one thing that so many programers have problems with in their earning stage, its data types and this is one area where assembler is a clear winner, what you need to know is how BIG the data is and if it is signed or unsigned if it matters.

I understand Thomas's view on what constitutes "dirty" code but its only "dirty" in the context of needing to port it to another platform on different hardware, in assembler you use the SIZE of the data and what you often do is SIZE cast a memory operand for an instruction.

Concept programming is a different animal to hardware programming and this is how I would characterise OOP C++ to assembler code. Where they meet head to head, assembler wins because it is platform specific but htey are still different animals. The other factor is of course that you can write modules in assembler for C++ if you are not committed to porting the code to other hardware and even if you do, just have a HLL version of the function for the build for the other platform.

The argument about bad asm being worse than good C has always been a lame duck, bad C is worse that good VB and a good batch file may be better than bad VB. Comparisons come between people who are competent in what they write, not on a theory that assumes that one form is better written that another.

Regards,

hutch@movsd.com
Posted on 2003-03-31 05:35:50 by hutch--
thing is, it's easier to write "good" code in C (and even moreso in C++) than it is to write good code in assembly, at least when using standard tools and techniques. I think even a lot of assembly programmers will agree on this.

One obvious advantage of HLLs is that you don't have to worry about running out of registers, and that you don't have to constantly shove stuff around. That you don't have to worry about every little detail, but can focus more on the overall design (and of course return to the little details if you need to).

Data types... are another great benefit. They can help catch a lot of annoying bugs early on. And it's not like C++ has a lot of stuff built-in, nor that it's very confusing. WIN32 has a shitload, and I wouldn't recommend learning win32 and a HLL at the same time; WIN32 is bad enough on it's own - it could have been done better, especially if microsoft had ditched all the legacy code and made that run in a subsystem sandbox. But they didn't, and we live in the real world.

Worrying about the SIZE of the data instead of the use seems a bit absurd to me. A spoon and a knife have similar sizes, but different uses, to make one of those silly comparisons. Win32 coding unfortunately, because of it's bad design, has a lot of typecasts everywhere when programming it "raw" from most HLLs. But the ideology of masm32 to just assume everything is a dword is just about as bad - it's suddenly not very evident what is a pointer and what is an integer. While it would be nice if programmers were flawless, most of us aren't, and it's nice to have a compiler catch obvious flaws of the typo kind.

Which language to use of course depends on a lot of things. Unfortunately, around here one of the most important factors seem to be 'zeal'. This thread will probably (unfortunately) devolve into one of those boring old klich?s. It is my belief that if you dedicate the same amount of time to learn assembly and C++ coding, and end up "equally skilled" in both, you can write code somewhat faster in C++, and it will be somewhat easier to track errors. Of course such a comparison is somewhat silly to make, as most people will develop a clear language preference and dedicate most of their time to this language.

But while C++ has more facilities to write good code than assembly typically has, in the end it depends extremely much on the programmer. C++ won't automatically make your code clean, it's still very easy to create bad and sloppy code, just like it's possible to create clean and nice code with assembly. Just happens to be that most assembly code I've seen floating around has been spaghetti mess with prehistoric coding principles, unmaintainable mess, that would probably even be beaten by most C++ compilers. I really don't want to insult anybody, but if you're programming in assembly you might as well do it right. Compilers are stupid and work out of a rigid set of heuristics, but today they can do a lot of smart tricks that aren't as trivial for a human being. Such as global optimizations, dead code removal, etc etc etc.

Good software is about stepping back a bit and look at the bigger picture; with assembly it's all too easy to get lost in the details. It doesn't _have_ to be that way, but it all too often happens. Probably something about the mindset you get in. It becomes silly when people start hand-optimizing messageloops, message dispatchers, and do microoptimizations all over the place.

C++ (and HLLs in general) aren't the holy grail, though. You still have to do design before hacking away, and you still have to think about the code you write. You can still easily shoot yourself in the foot, if perhaps for other reasons. But if done right, you don't necessarily get a much bigger runtime footprint nor much higher processor usage. C++ doesn't mean MFC nor BCB ;-)

And I'm not saying assembly is superfluous (though the necessity of it has been reduced greatly). There's still system-level programming where you have to go asm (not much of that under win32 though). There's still situations where you can't get enough speed, and can get gains from assembly optimizations (*after* you have chosen the optimal algorithm - doing heavy machine-level optimizing before thinking about algorithm design is of course stupid). There's still embedded platforms. There's still RTOSes. And even though hardware 3D acceleration has become mainstrem, there's still 2D routines to optimize.

But imho, the need for all-assembly is nonexistant, and is a hobby thing. It's tedious doing optimizations all over your program, and the typical "win32asm" coding style will yield poorer results than what most compilers output. Not that the code optimizations will matter on 90% of your application, heck for GUI-only apps they don't really matter at all. Yes, there's still people running p200's - I have been using one for a while recently. And I can say that for most win32 application programming, making stuff run well on older machines is more about good program design, algorithm choices and memory usage considerations, than micro-level assembly optimizations. The big picture.

If you code fast in assembly and don't make many bugs, good for you. I code faster in HLLs, thus that's my primary choice. There's no need to start any flamewars or whatever. I guess a lot of people won't like the next sentence, though.

There isn't much need for assembly anymore. There's greater need for good programming principles than ever before, though.
Posted on 2003-03-31 06:27:33 by f0dder
Hi Thomas:


From the leave's in your code I see you were using the proc statement. I didn't . In procs, the 'ret' opcode is actually a macro so probably MASM will now know the proc will end and never fall through the .IF construct.
My examples were just plain code (no procs), that's probably the reason I got the jumps and you didn't .
So as long as you use them in PROCs no jumps should be generated.. that's nice at least.


I did a little more experimentation, and you're right. Once I converted the .elseif version to plain PROC-less code, the phantom jumps magically appeared. I also put the code inside a PROC/ENDP block without any arguments or locals, and it generated the exact same code as the PROC-less version. But in all cases, once I eliminated the .elseif's the jumps went away.

One construct I like to use a lot (which I'm sure a lot of other MASM programmers use) is this:



.repeat ; once
. . .
.break .if (. . .)
.break .if (. . .)
. . .
.until 1


MASM generates no overhead for the .repeat loop, and the .break's are a great way of doing a structured downward goto.
Posted on 2003-03-31 08:26:35 by MANT
f0dder,

I know where you are coming from with your opening comment but it does have an assumption level that would not be held universally from programmers with a different background. Pascal programmers would like C/C++ a lot less than C programmers would, the same with Basic, Forth and similar other languages.

Comparisons are usually best between people who are competent in the language they choose so while it is often the case that a HLL programmer can write something faster than in pure assembler, a very large number of assembler programmers write in HLLs anyway so an informed choice is better than a forced one.

Certainly compilers have got better on average and if you want to work within their design framework, fine but the alternatives are what many HLL programmers want when the write assembler and assembler programmers with experience in both write what best suits their task at the time.

Data sizes are a different matter, by far the greatest source of mistakes made by entry level programmers is in the choice of data sizes. This is not helped by familiar expressions being used with compilers across different platform so a short can have different sizes and an INTEGER can be 8, 16, 32 or 64 bit in size depending on the platform. At a high level this matters less but with assembler, you must fit the data to the register you choose, no matter what.

Endless renaming of a data size increases the complexity for no viable reason, if you read the function definition, you will know if a return value is an address or not, calling it a POINTER data type does not help here any. Same for handles, brushes and anything else that resolves to a set data size. It is related to portability, not platform specific efficiency.

Regards,

hutch@movsd.com
Posted on 2003-04-07 04:02:44 by hutch--
I think that compilers will never beat out a human writing in assenbly
hll compillers are writen to use the slowest insructions and the slowest ways of moveing data around like putting every thing on the stack insteds of useing a memory location another thing I question is speed of programming
the rules of lanuage use dose make a lot of taskes harder in hlls than in assembly try writing a game of brake out or an editor in assembly then in an hll
pico vs e3 pico 160k e3 12k and e3 works just as well some times better than pico saying that speed and size dosen't count any more is an M$ way of thinking is doing less with more realy as good a thing as M$ would have you think
Posted on 2003-04-24 19:38:24 by rob.rice
Hi Rob:

I don't know the products you're comparing, so I can't really comment on those. It could be that pico has a lot more functionality, it could be that it's pulling in a bunch of unneccessary libraries. However, I do have to say that Microsoft C/C++ generates excellent quality code. In release mode, it tries very hard to avoid using a stack frame if it can avoid it, and I've seen some very clever use of every available register. It's really quite cool.

However, I do believe, and I've said it here before, that thinking in assember is where you get a lot of benefit. By dealing with the details, you get very familiar with them, and ideas spring up out of nowhere on how to speed things up and/or shrink the size down.

Just the other day I was working on something dealing with data pairs with a dependency graph, and I battled with it for a while trying to figure out a high-level solution to the problem (cycle detection, topological sorting, etc). In the end, I finally realized that the low-level approach was the answer. It was much faster, and actually easier to program.

I did this for work, so it had to be in C, but I believe it was the fact that I tackled the problem at a low level that really helped here. I got that kind of thinking by doing a lot of assembler coding. I think all of my programs, no matter what language I use, are better because I know assembler. I'm sure yours will be too! :alright:
Posted on 2003-04-24 22:26:52 by MANT
Originally posted by rob.rice
I think that compilers will never beat out a human writing in assenbly

True, but the human has to know his stuff well.

hll compillers are writen to use the slowest insructions and the slowest ways of moveing data around like putting every thing on the stack insteds of useing a memory location another thing I question is speed of programming

So you're saying compilers will put absolutely no effort in optimizing anything, it will always just choose the easy way out. Do you even believe that yourself? Of course compilers are very complex programs with a lot of algorithms to carefully optimize the code it outputs. Just look at the disassembly of a compiled C++ routine and you'll see (and don't look in debug mode :), it will choose the easy ways there).

the rules of lanuage use dose make a lot of taskes harder in hlls than in assembly try writing a game of brake out or an editor in assembly then in an hll
pico vs e3 pico 160k e3 12k and e3 works just as well some times better than pico saying that speed and size dosen't count any more is an M$ way of thinking is doing less with more realy as good a thing as M$ would have you think

Absolute speed measurement doesn't count. Would you even *feel* the difference between an editor in asm and one in C++ of which 90% is GUI stuff? You might notice it in things like searches in big texts but even there the algorithm used is more important than the language.

Thomas
Posted on 2003-04-25 02:50:52 by Thomas
Assembly does have its use in final algorithm optimization, though. Things like being able to go from average 4-5 cycles/operation to 0.484 cycles/operation speaks for itself :)
Posted on 2003-04-25 02:55:15 by f0dder
=======================================================
So you're saying compilers will put absolutely no effort in optimizing anything, it will always just choose the easy way out. Do you even believe that yourself? Of course compilers are very complex programs with a lot of algorithms to carefully optimize the code it outputs. Just look at the disassembly of a compiled C++ routine and you'll see (and don't look in debug mode , it will choose the easy ways there).
=======================================================

I am saying ALL data acess in Hlls is done throught indexed addressing these are the slowest operations a cpu can do and pointers working on arrays are even slower because thay are regster +regster + offset based indexing
as far as I know there is no way aroung useing pointers on arrays (but I may be wrong on this )
no matter how much optimizing is done by the compiler there is olny one heap
and ALL data is indexed from the start of the heap and stack opperations are still indexed in pure assembly there is almost no need for indexing data BUT you can still index data if you want the the up side of indexing is that it can save some space and will make some tasks easer

pico is a text based editor and dosen't have any more functionalty than e3
if you count the interface modes in e3 e3 has more functionalty than pico
e3 has WP mode,EMACS,mode ,VI mode pico has just VI mode
in search and replace e3 puts pico to shame pluse e3 can pipe the the file you are working on through sed and use sed to do extremly complex things to the file and bring it back to e3
the biggest problem I have with e3 is that the auto repete is way to fast

If you saw a human write assembly the way compilers do you would call hem ( or her) the sloppyest assembly programmer in the world

One hidden pluse to learning assembly is that it helps one understand digital
electronics
Posted on 2003-04-25 10:48:14 by rob.rice
Originally posted by rob.rice
I am saying ALL data acess in Hlls is done throught indexed addressing these are the slowest operations a cpu can do and pointers working on arrays are even slower because thay are regster +regster + offset based indexing
no matter how much optimizing is done by the compiler there is olny one heap
and ALL data is indexed from the start of the heap

What do you mean by ALL data access is done by indexed addressing? Of course it isn't, if the compiler can use a register it will use one. Or do you mean C++ class member access? In that case, yes a lot of indirect access is done there but you would need to do the same in asm.. Objects have the property that they are instances of a class, each one has its unique data. Of course you need indexed addressing to get those members, because it depends on the object pointer.
But the same thing would happen if you use dynamic memory in assembly to store some structure or data.
This is just me guessing, I don't really know what you mean by the above statement, could you give an example of it?

pico is a text based editor and dosen't have any more functionalty than e3
if you count the interface modes in e3 e3 has more functionalty than pico
e3 has WP mode,EMACS,mode ,VI mode pico has just VI mode

I don't know all these editors but this wasn't about functionality, was it?

If you saw a human write assembly the way compilers do you would call hem ( or her) the sloppyest assembly programmer in the world

No I wouldn't. A *lot* of asm programmers produce far worse code than compilers (usually the 'asm rules, C sucks'-type of programmers fall in this category).

One hidden pluse to learning assembly is that it helps one understand digital electronics

True, assembly has a lot of good educational features.

Thomas
Posted on 2003-04-25 11:09:29 by Thomas
back to what I sed to begen with I think that a compiler will never do better than a human when it comes to writing assembly code

If the data is stored to the heap it is done with indexed addressing
when data is retreved from the heap it is done with indexed addressing
most of the time when arguments are passed to a function it is done with
indexing in one form or another ( yes there some regster based functions )
even the windows API is (as far as I know) stack based

Tomas you seem to have forgotten there is regster indrect addressing
and it is a whole lot faster than indexing ( and smaller)

functionalty was used as a posable excuse for pico being so much bigger than 3e

I never sed C sucks I sed a humen writeing in assembly can always out do C
just like there are rotten assembly programmers there are rotten C programmers
that there rotten HLL programmers seams to be getting over looked
and a rotten HLL programmer will be even worse at assembly ( there is more to get wrong)
Posted on 2003-04-25 11:51:37 by rob.rice
I don't know all these editors but this wasn't about functionality, was it?


I brought up the possibility that pico was bigger perhaps because it had more functionality. I don't know these editors either; I was just speculating.

If you saw a human write assembly the way compilers do you would call hem ( or her) the sloppyest assembly programmer in the world


I agree with Thomas, I wouldn't say that either. I think many compilers do a really good job of local optimization, and many assembly programmers write really horrible code.

Also, an operation like MOV EAX, is just as fast as MOV EAX, or even MOV EAX,EBX on today's Pentiums.

What's slower is MOV ,EAX compared to MOV EBX,EAX because it's writing to memory.

I've seen MS VC++ hold a whole lot of data in registers to avoid writing to memory. I honestly think compiler optimization is pretty good as far as it goes. What compilers will not do is heavy-duty optimization. But neither will an average assembler programmer: you have to be pretty good to optimize well.

But that's all looking locally. When you step back and look at the application as a whole, I don't think anything but assembler and maybe Forth will give you a really small application.

Before bashing HLL's by comparing a large program with a small one, I'd suggest you try to get as much information as possible about both. Maybe pico really is bloated simply because of the HLL it was written in, but without any data, there's not much in the argument for me to believe. If you can provide more information on these two editors, I think many of us would be interested. What I'm not interested in is unsubstantiated rants! ;)

Fast programs: some assembly required! :alright:
Posted on 2003-04-25 11:52:36 by MANT
Originally posted by rob.rice
back to what I sed to begen with I think that a compiler will never do better than a human when it comes to writing assembly code

Again, this sentence isn't true unless you add that the human is actually a good asm programmer. A beginner in asm will produce worse code than a compiler.

Originally posted by rob.rice
If the data is stored to the heap it is done with indexed addressing
when data is retreved from the heap it is done with indexed addressing
most of the time when arguments are passed to a function it is done with
indexing in one form or another ( yes there some regster based functions )
even the windows API is (as far as I know) stack based

This has absolutely nothing to do with the difference between asm & HLLs.. If you store something on the heap you need indexed addressing, no matter what language you use. If you don't, you don't need it. It's as simple as that. But you can't use this as an argument to program in assembly, it isn't language specific.

Originally posted by rob.rice
functionalty was used as a posable excuse for pico being so much bigger than 3e

Originally posted by MANT
I brought up the possibility that pico was bigger perhaps because it had more functionality. I don't know these editors either; I was just speculating.

Sorry, I missed that in the thread. But size isn't everything. HLLs often use a library of standard functions, of which the basic startup code and widely used functions are almost always included. If you look purely at the code you wrote yourself, there probably won't be much difference between C and asm. C++ might add *some* overhead but you get objects and classes for it in return.

I never sed C sucks I sed a humen writeing in assembly can always out do C
just like there rotten assembly programmers there are rotten C programmers
that there rotten HLL programmers seams to be getting over looked

There are bad programmers in every language. But even writing 'correct' code in assembly won't automatically beat the compiler.

Thomas
Posted on 2003-04-25 12:41:18 by Thomas
Originally edited by rob.rice
and a rotten HLL programmer will be even worse at assembly ( there is more to get wrong)

I disagree. Just look at how many programs that popup here will crash at various system because of registers that aren't saved, you would never see that in a HLL program. Also C(++) for example has strong type checking, it will warn you if the type isn't correct while an asm programmer will not notice it until it crashes (because "everything is a dword").

Assembly let's you do anthing, HLLs usually restrict you to what's right. Now what would lead to less errors?

Thomas
btw you might consider using punctuation :tongue:
Posted on 2003-04-25 12:47:33 by Thomas
Before bashing HLL's by comparing a large program with a small one, I'd suggest you try to get as much information as possible about both. Maybe pico really is bloated simply because of the HLL it was written in, but without any data, there's not much in the argument for me to believe. If you can provide more information on these two editors, I think many of us would be interested. What I'm not interested in is unsubstantiated rants!

what would you like links to the source code ?

I can tell you right now e3 source code is hard to read because
the same source is used for more than one OS (hence more than one API)

so who is ranting I am saying assembly will out preform HLLs
and I can see that I am not alone in saying this and that alot of things
are easyer in assembly
Posted on 2003-04-25 12:51:02 by rob.rice
what would you like links to the source code ?


That would be a start, sure.

But you brought up this argument -- and so far all you said was basically: pico is much bigger and written in a HLL, and e3 is assembly and smaller, so assembly must be better. An argument like that is not really very persuasive for me because it lacks supporting data.

Since you're asking what I'd like to see, I'd say the answer would be for you to analyze pico and try to figure out why it's bigger. Take the standpoint that you're trying to defend it instead of attack it. Look at the complete list of features it offers compared with e3. Maybe it's bigger because it links in a whole bunch of unneccessary library code. Maybe a better linker would be smart enough to remove all that dead weight, and the two programs would be more similar in size. Maybe not.

Without more information, I really don't know what is going on.

You said pico is 160 K and e3 is 12 K. That's a huge difference. There's absolutely no way you can use that to compare HLL's vs assembly. As much as I love asm, you're not going to save that much code. That's either functionality (like full regular expression support, for example) or library code being pulled in (which you can do with asm too).

As I said before, I'd be very interested to see a real analysis of the two apps someday.

:alright:
Posted on 2003-04-25 13:11:20 by MANT

Before bashing HLL's by comparing a large program with a small one, I'd suggest you try to get as much information as possible about both. Maybe pico really is bloated simply because of the HLL it was written in, but without any data, there's not much in the argument for me to believe. If you can provide more information on these two editors, I think many of us would be interested. What I'm not interested in is unsubstantiated rants!

what would you like links to the source code ?

I can tell you right now e3 source code is hard to read because
the same source is used for more than one OS (hence more than one API)

I don't really see why these programs are so important for this discussion, I can think of many examples where assembly has been put to good use. My main point is that assembly isn't always better.

so who is ranting I am saying assembly will out preform HLLs
and I can see that I am not alone in saying this..

Again and again: Just writing in asm won't outperform HLLs.

... and that alot of things
are easyer in assembly

They are easy because assembly allows a lot, you're more free. The price you pay for this is that it's easier to do things wrong too.

Thomas
Posted on 2003-04-25 13:19:52 by Thomas
yes and you can do things wrong in Hlls to big things in HLLs
small things in assembly

a human can pull back and look at the task at hand
a compiler can't do that
compillers have gotten a lot smarter BUT thay at there
best look at one function at a time not the whole program
and no compiller will ever be smarter than a human
a compiller can't restrecuter the program the way a humen can
and useing an Hll the human cant see how restructureing
will help when it can help ( I'm not saying that it will always help)

there is also the matter of uneeded overhead that always comes
with HLLs you can't turn off just the useless parts of this over
head but you can turn off all of it and rebuild the parts you need
the compiller can't see what is going to be done it just gets ready
for every thing that can be done to be done this is part of what
I mean about humans being smater than compillers
( I'm talking about the startup code in C and other HLLS)
the overhead of useing libaray functions can't be gotten around

and there some things that can be done in assembly that HLLs
are just can't easly do like bit manipulation

I am not saying that HLLs are useless but thay are not always
the best way to do things

a rotter assembly programmer will most likely be a rotten Hll
programmer Hlls are not a fix for not knowing what you are doing

and yes one needs to know a whole of a lot more to program to
program in assembly than HLLs but at the same time one gains
a better understanding of how computers work even if you never
programs in assembly this alone makes it worth learning
just learning assembly will make you a better HLL programmer
Posted on 2003-04-25 13:28:16 by rob.rice