Why program in Assembly!?

[Aedan]

Originally posted by Lovechild
ASM is damn useless to be honest, developing goes so slow compared to C++ or Python.

But it's totally 1337 to be able to read and of course write it, plus it's good for making hardware drivers.

ASM is darn good for some tasks. Generally tasks that require small memory footprints, or have to run on fairly low powered devices fair well in assembler.

As far as writing hardware drivers - most of it can be done in C quite happily. Typically you'd just write small segments (time critical or sensitive) in assembler.

Áedán

[DimViesel]

Unless they were of course the requirement for applicants be that they be assembly programmers Postaldave!

It is a fallacy that all or the majority of jobs call for C++ developers the majority of the time. I think the overriding factor will be whether the team is beginning at stage -1 or restructuring an existing system or project.

I get the gist of what you are saying, although I think it may be a case of some good points badly made.

The reason for recommending Pascal to 'beginners' (people who want to master programming of some form or another), is that it goes some way to encouraging (and enforcing) a method of laying out and writing that benefits from being more readable clearer sequentially and attemps to address some of the ambigious aspects of BASICs operators (the assignment in particular which doubles as a comparison operator which is was we commonly refer to as 'equals' this little fella '=' ).

Also I think I have to point out that anyone with their knowledge and mind in the right place would not begin to argue that one language is better. These are subjective arguments along the lines of whose way of abstracting the world is better. (What is in fact missing from such statements, to make them workable, objective arguments is to define better is; better than what? Better at what?) While not deviating too far from what comp languages are about I feel this is as good an analogy as I can think up without financial encouragement.

No way of abstracting the world is superior in totality than another valid and logical abstraction. They all have their place and part of the mastery of them is to know when they are most apt and when they may lead you up the garden path.

{ Believe it or not almost all of us were noobs once upon a time (that was for the people who seem to actaully believe they were born coding, although sometimes it can seem like they must have been!). . . I don't think genetic engineering stretches to embryonic software engineers yet, so we all leave the womb as nooblike as the next earthling. The only thing that differentiates us comes later when some of us choose to forget this humble starting position faster than others and that perhaps we would not have got so far quite so quickly without the unconditional and timely guidance of the odd sould here and there. Pascal would have been my first language had I not met basic first. It's inevitable, its everywhere. }

[Aedan]

Originally posted by DimViesel
Pascal would have been my first language had I not met basic first.

BASIC was my first language, closely followed by 6502 assembler, followed by 68K assembler. Then I discovered things like Pascal, C, Ada and others.

Áedán

[DimViesel]

Today that would seem like an extreme and outlandish sequence of languages to learn and the learning curve could be described with similar terms!

However with some the mention of some of the CPUs you cut your coding teeth on you are inevitably giving away that you are from the generation before mine Aedan.

Or perhaps you really have been coding since you were in the cot.


Nice to know there are some old hands with the old assm in the forum though... although we probably would use it (assembler), you and I, for entirely different things.

I feel a new thread is looming nerviously in the wings . . .

[Allan]

Originally posted by DimViesel
I have to just say,
although this is probably not the place:
that is one fine hat you have Allan!
Jeez!

You Danish cowgirls are soooooo HOT ! :devil:

Hoochie Mama!

Ahooooogah!

Hits himself with a copy of Amiga Machine Language by Stefan Dittrich 1989(!) edition (in quite good condition - the book that is!)!!!

(Oh!. . . The 68000. . . Where art thou 68000. . . -listlessly hums himself to a state of hippy calmness. . .):clown:

(The author takes no responsibility for his clowning around, but does wish it to be clear that he means it completely in light jest,
and does not wish to offend anyone in any way merely entertain with surreal humour, if only briefly. Moderator feel free to remove
or edit if you so deem, alternatively the author will delete the post at the first sign of any sincere objection.)

LOL thanks, I'll be sure to tell her about this post!

As Aedan points out, the girl in the picture is not me (well DOH) but my lovely girlfriend through 2+ years now, Bettina.

The hat is mine, brought all the way home to me from Australia by my older brother. Real leather, real crocodile teeth! Hoo-ah!

[Gizmo]

Originally posted by Áedán


BASIC was my first language, closely followed by 6502 assembler, followed by 68K assembler. Then I discovered things like Pascal, C, Ada and others.

Áedán

Hmmm..........lessee............started with Basic on a TI-99/4A. Got an Atari 600XL, learned AtariBasic, then learned 6502 ASM, and then Forth and Action!. Then got an Atari 520ST, followed by an Amiga 500, followed by an Atari Falcon030. Learned 680x0 ASM, Atari STBasic, and C (Mark Williams and Borland Turbo). Then got a PC, learned 80x86 ASM (which I LOATHE), C++ (Microsoft MFC and Borland OWL), Java, Quick Basic, and Visual Basic. Along the way, I picked up Z80, Z8, and 8051 assembly. Hmmm, anybody see a pattern here? I've also done some Pascal and COBOL, but I wouldn't say I am proficient in those.

Given a choice, I prefer to code in ASM (even on the x86). Why? Because REAL programmers code in ASM, that's why!

For pure, raw, unbridled speed and power, NOTHING touches ASM. It is SUCH a rush to see a program that used to crawl fly by so fast you think something is wrong. You don't have to deal with screwball compiler optimizations. There are no surprises. The program does EXACTLY and ONLY what you tell it to do.

However, I'm rarely given the choice. Interfacing an ASM program to a C or C++ application usually involves jumping through hoops. And most of the people who pay my checks don't give a crap if the high-level language I write in requires more powerfull hardware to get reasonable performance, because Moore's law has spoiled them. What they care about is that I can write a program in C in about 1/4 the time I can do it in ASM. Granted, the ASM program will generally run 4 times faster (or better, some times as much as 10 times faster) and have about 50% smaller memory footprint, but that doesn't have an impact on the company's bottom line. Being able to get me off the current project and onto a new one does.

The biggest drawback to ASM is, IMHO, the amount of time it takes to find a bug. Things like local variables and variable scope don't exist in ASM; EVERYTHING is a global variable. That means that you can end up with some nasty, NASTY memory management issues.

[Gizmo]

Originally posted by DimViesel
Today that would seem like an extreme and outlandish sequence of languages to learn and the learning curve could be described with similar terms!

I suppose that depends on your definition of outlandish. I've yet to encounter a programming language that I wasn't able to pick up in the space of one to two weeks. Often, I spend more time fighting the quirks of the support package and compiler than I do the language (for example, it took me almost two MONTHS to get even PASSINGLY familiar with all of the crap in Borland's Object Windows Library or the Microsoft Foundation Classes). In any case, all ASM languages that I have experience with have 60 or less basic commands and twenty or less different rules for combining the commands to create the individual instructions (the 6502 had 55 instructions TOTAL, including all of the variations for addressing modes; the 68000 had something like 4,000; I've not bothered to count the x86 instructions ).

[DimViesel]

Originally posted by gizmo
... I've yet to encounter a programming language that I wasn't able to pick up in the space of one to two weeks. Often, I spend more time fighting the quirks of the support package and compiler than I do the language (for example, it took me almost two MONTHS to get even PASSINGLY familiar with all of the crap in Borland's Object Windows Library or the Microsoft Foundation Classes...

I'm not going to argue with you at that point Gizmo, for I believe and can see, that you verily speak the truth. The, 'crap in Borland's Object Windows Library', or as you say,'or the Microsoft Foundation Classes' is indeed a hassle to assimilate.

The previous post was elucidating, and a good tale of ASM from a 1st hand perspective. I belive your opinion of compiler optimisations sheds some light on the usual 'coding in assembler is obsolete because modern compilers produce as optimised code as the average ASM programer' argument.

However going back to the point illustrated by the quote above, its comparing apples to oranges to say that because it has no 'logical layer' akin to the one that has to be covered before you can feel 'at home' with an OOP language or another high level dev tool that asm is quicker to learn. We must not get trapped into arguing over terminology. When I speak of learning a [formal computer]language I do not consider knowing the set of reserved words or instructions sufficient. I mean the point where the knowledge aquired permits the user to write apt solutions to problems which are well defined and perhaps at some reasonable rate correcting a reasonable amount of errors as he goes along. I think you have to agree it would take more than a couple of weeks for a learner to have got his head around the intricacies and idiosynchracies of the particular architecture he was working on before he had actually mastered the use of a particular ASM.

Then again my experience of ASM is v. small. I am arriving at this conclusion from fundamental understanding of Computer Science rather than personal findings.

It would be great to get your thoughts on this.

[Gizmo]

Originally posted by DimViesel

I belive your opinion of compiler optimisations sheds some light on the usual 'coding in assembler is obsolete because modern compilers produce as optimised code as the average ASM programer' argument.

Hmmm...........I didn't mean to start THAT discussion back up.

For most code written by your average programmer, modern optimizing compilers can do a pretty good job, and they are steadily improving. Believe it or not, I have actually learned a couple of tricks from disassembling the code produced by compilers. The thing is, a compiler can only produce optimizations at the local level. It doesn't have the big picture about what problem the application is trying to solve, and so misses things that a good programmer will be able to do because he has the totality of the solution in his mind.

Originally posted by DimViesel

We must not get trapped into arguing over terminology. When I speak of learning a [formal computer]language I do not consider knowing the set of reserved words or instructions sufficient. I mean the point where the knowledge aquired permits the user to write apt solutions to problems which are well defined and perhaps at some reasonable rate correcting a reasonable amount of errors as he goes along.

Ok. For the sake of discussion, I will accept your definition, although I don't completely agree.

Originally posted by DimViesel

I think you have to agree it would take more than a couple of weeks for a learner to have got his head around the intricacies and idiosynchracies of the particular architecture he was working on before he had actually mastered the use of a particular ASM.

Oh, I wasn't attempting to suggest that I could MASTER a language in the space of a couple of weeks. I was simply stating that I could begin being productive in a language in a couple of weeks. Mastery of ANY programming language can potentially take months or even YEARS of work. (Example: You argue that VC++ with MFC is a language unto itself. I have been working working with MFC non-stop for nearly two years. I consider myself proficient in this language, but I would NOT call myself a MASTER. About the only language I would consider having ever MASTERED would be 6502 ASM, and that was 20 years ago.)

[DimViesel]

"It doesn't have the big picture about what problem the application is trying to solve, and so misses things that a good programmer will be able to do because he has the totality of the solution in his mind" - Precisely.
In other words . . .Whaddahya know ? A compiler is not intelligent, it is only a program!

Funny how many people don't get this. . . - oh yeah I forgot - they are not programmers. (Although paradoxically it is programmers who are making compilers better- and writing themselves out of a job in the process - therefore sure, you can pick up tricks from a compiler, since you are in fact picking them up from the designer who put them there in the first place.
Computers do not yet build themselves. . . that comes later!

[msfmzat]

Do you have any sites to start learning Pascal then? It sounds very interesting.. I don't have any experience in programming.. I started learning html and that kind of thing..but thats not even close to the same.. I'm looking to learn how to program and this sounds like it might be a good start.

[Allan]

I'm learning ASM this and the next semester. We haven't come very far yet though, but it is very interesting so far.

Making arrays, copying them, writing to the monitor, moving stuff around in mem and registers etc. Well, all basic stuff. But I'm sure that will change soon...

oh, and I'm doing C++ too now. Copy constructors, operator overloading, and next week inheritance and then later on polymorphy. Fun, fun, fun!
Last semester was more basic though. Like with everything else new.

[Allan]

Today we wrote ASM "drivers" for an IO card on the SBC. However, the drivers only handled 8 LED's and 8 DIP switches. We're writing procedures with input parameters and return parameters now (You know, always return in AL/AX/EAX for Byte, word and double word) etc.

[Aedan]

Nearly as much fun as passing parameters on the stack... It's more fun when you start having to deal with more interesting examples, honest!

[Allan]

Originally Posted by Áedán

Nearly as much fun as passing parameters on the stack... It's more fun when you start having to deal with more interesting examples, honest!

I don't doubt that! I look forward to putting more "grrr" to it, if you know what I mean.

But alas we have to start with the basics.. and PUSH'ing parameters onto the stack is one of them.

[Allan]

This week we wrote ASM drivers for a PPI in mode 0. (3 in/out parallel ports, A, B and C). A simple driver, but still a bit more of a challenge than the previous assignments.

In C++ we are through to templates atm. Last few weeks were inheritance and polymorphism...

[XLCH]

Assembly is a technicians/engineers language.
Program may have more lines of code but it runs faster.
Useful in repair/testing, kinda like making a dead frog's legs move with an electric current. Everything has it's use. No good or bad.

[Gizmo]

Discovered another one of those 'screwball' compiler optimizations that I love today....

Consider a class in C++. You write the declaration (.h) and the implementation (.cpp). Now, some functions in the implementation are very simply one liners, so you go ahead and write the implementation as part of the definition. As an example, you do the following in the header file:

int Class::Version() {return DEFINED_VERSION;}

So far, so good. This compiles and everything seems hunky-dory. The problem here lies in the fact that many optimizing compilers will take this implementation and, because it is defined in the header file, is a simple one-liner, and is returning a constant, instead of compiling the call-return sequence that would be used for a regular function, this call gets compiled into a hard constant in the final application. So far, so good.

At some later point you decide that this class is usefull enough to make into a DLL, so that you don't have to include this code in every app that uses it. Since the version checking call above is compiled as a hard constant in the app, you can end up using a dll with a version other than that what you are checking for and NOT KNOW IT! The only way to solve this problem is to take the one-liner out of the header and put it into the implementation, so that it is part of the dll and the link library.

I encountered this little gem today and spent the better part of 2 hours trying to figure out what was going on. It was only when I looked at the assembly output of the compiler that I realized what had happened. The nasty part about this is that when I ran the code in debug mode, everything worked right. That is because, generally, when you compile an application in debug mode, all optimizations are disabled.

Just thought that you guys might find this real world example of how compilers can sometimes screw you to be helpful.

[Allan]

gizmo, what compiler was that? Thank you for sharing your experiences here - I'll keep this lil problem in mind.

[Gizmo]

It was the Microsoft Visual C++ 6 compiler. I've been told that the Borland Turbo C compiler does it as well.

It's actually a pretty good trick for optimization which normally works pretty well. The only reason I even discovered it is because I was tracking another problem in some code that someone else wrote and stumbled across this little gem in the process. As a matter of coding style, <I> would NEVER write code this way, but it is a fairly common practice.