I didn't say you couldn't. I said it's easier to do something wrong in asm.

Posted on 2003-04-25 13:32:15 by Thomas
right now is not the best time for me to be talking about this
I keep getting called away from the computer and have to
post unfinished thoughts please re read my posts I have edited
them to finish my thoughts
Posted on 2003-04-25 14:10:07 by rob.rice
Originally posted by rob.rice
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 re strecuter 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)

That's a different level of optimizing, there's code level optimizing and algorithm/design level optimizing. Compilers don't come up with algorithms or designs, that's the part the programmer has to do (what else is programming for?). This is true for both assembly and HLLs. The thing you're talking about is not a task of a compiler, you might as well say that asm programmers are better because humans can talk and compilers can't. No matter what language, the design and algorithms have to be figured out by the programmer.
The difference between HLLs and assembly is with HLLs, the programmer focusses on the design, while with asm, the programmer has to do both the design and the code level details (optimizing). In cases where the design matters more than the speed gained by optimizing the code level by hand, I pefer HLLs but that's my choice.
It's true that the structure of an asm programming is more 'low-level' than a HLL program structure, but this has both advantages and disadvantages. HLLs often have nice features for creating data structures and designing programs (classes, interfaces, design patterns). In assembly, none of these present by default. You all have to do this yourself. Often asm programs lack any good design, but this too depends on the programmer. It's just that HLLs provide the basic elements for good design so chances are higher one will have a working design in HLLs than without these basic elements. Sometimes asm programmers tend to think low-level all the time, while high-level design is just as important.

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

This is true for standard libraries that have standard functionality of which some things aren't used but still present. Personally I rather have some extra stuff I don't use than writing all those routines myself.
Btw the STL C++ classes are mostly templates with inline functions, the basic data structures (vectors, lists, queues, maps) have an overhead close to zero.

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

Most bit stuff is available in HLLs to (I've missed rol/ror a few times though), but it's true that these things are easier in assembly, because it's more low level. The use of (complex) bit manipulation is very limited in most programs though (the occasional flag check can be done just as fast in C).

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

Then we agree :) It's like saying the glass is half full or half empty: HLLs are not always the best thing but asm isn't always the best thing either.

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

But a good C programmer has to know a lot less than a good asm programmer. To beat the compiler you really need to know the CPU details, instruction timings, pipelines, cache stuff etc.

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

I totally agree but don't mix up educational use with practical use.

Just like you're not saying 'asm rules', I'm not saying 'C++ rules', I enjoy programming in assembly and use it where I think it matters, I'm only explaining my view on the use of assembly and how it compares to HLLs.

Posted on 2003-04-25 14:31:22 by Thomas
But a good C programmer has to know a lot less than a good asm programmer. To beat the compiler you really need to know the CPU details, instruction timings, pipelines, cache stuff etc.

so we agree that a good assembly programmer can beat a compiler
Posted on 2003-04-25 14:47:13 by rob.rice
Originally posted by rob.rice
so we agree that a good assembly programmer can beat a compiler

Certainly, I've always said that. It was you who forgot the word 'good' each time ;)

Posted on 2003-04-25 14:52:17 by Thomas
I have used BASIC for working out the algorithm
and recoded in assembly the style of BASIC is alot
closer to the style of assembly than any other
lanuage that I know of well fortran is close too

so even for writing in assembly HLLs some times have a place
Posted on 2003-04-25 14:58:55 by rob.rice
Why is ASM that is good Q & A

Q:Why is ASM
A:Just is I Like....

same is Why is C? not C++, Why is VB? not Dephi?
any thing just i like... if u like C++ just do it, not why....

for asm member will anser ASM will to Build a Samll and Fast program or code...
that too old Anser.. now CPU speed will fast more and Save Drivce will large more...

why is ASM ? my anser is very sample
that is "ASM" is my love...

:grin: :grin: :grin:
Posted on 2003-05-07 18:51:34 by swang
I use C++ when I need to simplify code and concentrate on the problem at hand.

For example, I am writing a bottom-up parsing algorithm which has a lot of code, and is definitely not easy to come up with. In C++, I can more easily maintain and modify my code, and I don't have to worry about the tiniest details.

Java, on the other hand, is an ugly language, both for the coder and the end-user.
Posted on 2003-05-17 14:15:34 by Paulicles the Philosopher
Microsoft build software to help an operating system not owned by them? Are you kidding? Even so, I'd hope developers and IT managers are smart enough to not be influenced soley by an ad on TV. Being a proven solution is what counts. J2EE has been proven many times. .NET has not.

I haven't read the whole thread yet but once I got to the above quote I had to comment.

I work in a pure MS shop building an ASP.NET application in VB.NET 90%, C# 10%. The app is for the insurance industry and we have about 10,000 users or so. That equates to about 50,000 requests per hour. We minimize postbacks as much as possible.

We have some very powerful datacenters and bandwidth is not an issue. It's a proprietary app but licences/rented commercially.

Scalability? We are able to sustain roughly 20,000 - 50,000 requests per hour (using SQL Server 2k on the back-end) and our latency is less than 2 seconds and in many cases we are about .5 seconds and 2 seconds worse case (except the few rare instances where some intense crunching and transactions are taking place then we push it off to the Message Queue and it takes 5 - 45 seconds but that's not core functionality so it's not an issue to be concerned about.

Stability? .NET has it's stability issues. In many cases I tend to be afraid a wee for some of our processes and code defensively moreso than I do in other languages that don't have stability isses but for the most part, it's very stable (our app always hasn't been and we did quite some work to make it stable).

In all, concerning stability of ASP.NET (version 1.0) really takes some knowing the architecture, how things work, good patience, good exprerience, good design, and lots of junk food but it's workable.

I am not a Java programmer so I can't comment on any of it's issues/merits but my experience with ASP.NET/C#/VB.NET has been very frustrating to get there but very rewarding when seeing it in action (our total database is about 100 TeraBytes or so) but partitiioned to clients that use about 1-10 TB). I'm not a DBA so I don't know the details.

Really, those who want to question .NET's scalability and performance are asking good questions and for the right reasons if they ask out of concern, but my experience thus far with it has enlightened me to the fact that it performs and scales quite well in the Enterprise.

Not withstanding we've had MS come and hand tweak a few areas in the past, the .NET development in our shop (about 50,000 lines -- some well architected, some thrown together like spaghetti (depends on the developer) has been developed independantly and tweaked independantly based on our frustrating experiences with the capability limits or just qwerkiness of ASP.NET... not sure which...

In all, I don't have too many concerns about ASP.NET now looking back on it... however I do realize it can be very frustrating to do seemingly simple things and getting high-performance results isn't a natural thing and really has to be worked out through trial-and-error but it's reasonably possible to get the end result but that requires developers with loads of experience (in development and computer science understanding) and isn't, in my opinion, going to be achieved by people with lesser experience and understanding. Most of our developers are at a senior level and we don't have any beginners on our teams. I don't think they'd be able to pull off the kind of results our business requires. But that's not the point I'm trying to make.

My point is that it handles itself quite well in the Enterprise and can easily handle 50,000 requests per hour (given the right hardware and bandwidth) given it was developed by experienced people that know how to come up with some creativity to get it there. You won't get that kind of performance from beginners or people that don't understand a bit about web development, but in the end, once you know what to do/not do and how to drive the ASP.NET/CLR, you can make it scale as high as you want.

Posted on 2003-05-25 02:52:41 by _Shawn
Advantages of Assembly: It is there, it has been proven to work in programming computers... so use it when you need it.
Advantages of C/C++: It is there, it has been proven to work in programming computers... so use it when you need it.
Advantages of... I hope people get the pattern forming here :)
Posted on 2003-05-25 13:21:51 by SpooK
Darwin can prove useful when talking about the merit of programming languages, but I still hate Visual Basic.
Posted on 2003-05-25 22:42:59 by Paulicles the Philosopher

but I still hate Visual Basic.

I don't like VB either but, I don't hate it, I let them VB-programmers live their lives in sowrrow ;)
Posted on 2003-05-25 23:19:02 by scientica
hehe, me and a friend of mine's been trying to convince each other to learn ASM/C++, he's a outstanding C++ coder, and i've decided i'm sticking to ASM, so there's been much dispute, etc. Our main topic was exe-sizes, but he had produced smaller exes than me (we worked on some project we had decided on, in ASM/C++), because i'm very inexperienced and tend to bloat code alot :(

ASM is quite interesting actually, i don't see a single disadvantage compared to C++ besides a VERY standarized programming habits (although many different "sects" of such programming styles have already been formed :tongue: ), although many jobs might require C++, knowning ASM can be quite useful indeed. I've recently began to start and learn Borland Delphi, it's syntax i find to be alot more cleaner than that of VC++, and i can produce fast stuff, and save lots of time, when size isn't a problem.

I also think VB is a piece of :tongue: , it has the worst syntax i've seen, and it is incredibly unlike any other language in that it has terrible language structure, and aimed for store managers who don't have time to learn some complicated language. Although i'm not saying there aren't very talented VB coders out there, i personally wouldn't reccomend it for beginners either.

If you learn one language quite well, be it C++/Pascal/ASM (the three most popular ones i know, at least for me and my friends), you can quite easily migrate to the other without too much problem!
Posted on 2003-05-25 23:43:06 by Drocon

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)

Take a look at GCC's output with -O3 enabled sometime.
It does some *very* impressive global optimizations.
Obviously, they are limited to the same source file, but I've seen it
replace a function call to some function (with nested function calls, too!)
with a single constant. Apparently, it computed the constant result that
the function would have computed and it did this at compile time.
It was very impressive, actually.

The thing that makes this thread go on and on forever is that
humans and compilers are better at optimizing different things.
It's very easy to provide an example of where a compiler will (typically)
do better than a human coder and vice versa. The only constant in
this argument is that the human coder can always look at what the
compiler has done and mimic that, the compiler can't look at what the
human has done. Then again, very few humans take the time to
write the code in some HLL *and* in assembly, so they rarely get
the opportunity to see how the compiler to do the same code they're
so proud of in assembly language.
Randy Hyde
Posted on 2003-05-30 15:21:03 by rhyde

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.

Wouldn't it be nice to have such a language construct built into the language so you don't have to deal with the confusion of misusing statements for purposes other than they are intended (e.g., using a repeat..until for something that is not a loop)? This reminds of the C idiosyncrasy of using "for(;;)" to create an infinite loop.

Wouldn't it be nicer to be able to say something like:

begin block;
exitif( --- ) block;
end block;

The reason for the labels, of course, is so that you can nest the blocks and branch out of any one of them. Still just as "structured" as your example and a little bit more readable and maintainable.

HLA, of course, supports these kinds of structures. Now HLA's optimization is not as complete as MASM's (re: those phantom jumps), but it is improving. In return, however, HLA provides a whole set of additional control structures that advanced programmers would find useful, including an "else" attached to while loops and for loops (e.g., when the expression evaluates false, the else section executes; however, if you break out of the loop the else section does not execute, which is *very* useful for certain algorithms). HLA also provides true iterators and a foreach loop. Finally, HLA provides really cool macros that let you *easily* create your own nestable control structures when you decide to create your own control structure that HLA doesn't support (something MASM's macro facilities are not at all good for; the lack of this feature is why I wrote HLA in the first place).
Randy Hyde
Posted on 2003-05-30 15:33:56 by rhyde
:-D I have 2 reasons :-D
(it's very important to me :)
2. asm is WYSIWYG lang: if you place push in your source - you will see push also in the debugger instead of _call_PushSubInDllOfUnlnownAuther
it is enought for me ;)

oh, not enought!
3. i also hate to remember all synonims of dd :-D
Posted on 2004-09-13 08:52:42 by Shoo
lol I thought I was the only one to hate those curly brackets :grin:
Posted on 2004-09-13 09:12:36 by Ultrano
nope, I too must confess a personal distaste toward those hideous, grotesque, gnarled and twisted brackets - they are visually displeasing, and they remind me of math - ewww !!
Posted on 2004-09-26 02:40:23 by Homer
I as well hate curly brackets, they get in the way of my spaghetti code. And as a fat guy, I must say I love my spaghetti! :-D

Bryant Keller
Posted on 2004-09-26 17:09:49 by Synfire
I may suggest we start an anti-curly-brackets movement :)

Someone mentioned here early that writing application in asm will take much more time than the same task in HLL. However people tend to exaggerate. Does it really worth it to avoid some more hours of coding just to get the thing completed faster (unless one have some short deadline).

Let's say someone writes a bunch of utilities to help him with project compilation. Of course it's written in C. Who ever will bother to do that in asm, when those utilities are only used at compiler time and not included in final project. But what if project becomes pretty huge and those utils total execution time takes 5% of overall compilation time. (imagine how much time can be saved with asm optimizations when overall compilation takes about 1 hour and done five times a day) Is the low level language still should be avoided ?

p.s this post isn't supposed to be one of those 'the assembler is better than hll' flamestarters. But rather a though about how one can manage himself one more coffee break by optimizing some, at a first sight, optimization unnecessary code :)
Posted on 2004-09-26 19:05:48 by arafel