Moderators: richierich, ua900, PanAm_DC10, hOMSaR

 
flyf15
Topic Author
Posts: 6633
Joined: Tue May 18, 1999 11:10 am

Assembly Language Programming

Wed Jan 28, 2004 9:36 am

First off, I know this is an extremely nerdy post...bare with me. I have a feeling some of you might know this.

I'm just now beginning to learn assembly language programming, working with the Motorola 68000 group of processors. I'm having some trouble, so I'm looking for a really good beginner-oriented book, website, how-to guide, or something similar to get started with and give me a good foundation.

Any help at all would be appreciated. Thanks guys!
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 9:56 am

I studied that stuff 10 years ago. Unfortunately I threw all my books away.

I remember I was coming from the 6800 family and, at first, I was a bit disoriented but after a while, it proved to be quite fun. The 68000 is very easy to program, except for the hardware interrupts, which are implemented in a very weird fashion (round robin or daisy chain, but don't remember that well).

Anyway, give yourself some times: I'm 100% positive it's easy. You'll probably find something interesting here.
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

RE: Assembly Language Programming

Wed Jan 28, 2004 10:17 am

The 68K CPUs actually are a pretty good start for learning assembly language; Very easy and elegant to code for - especially when compared to the abominable 80x86 family. Big grin

It may not be what you´re looking for, but I´d actually recommend the official Motorola user manuals with the instruction set listing.

Key is a good understanding of the register set and the instruction set. Everything else is derived from that.

Links:

"official" Documents are found here
(You´ll need the "68000 Family Programmer's Reference Manual")

Some more resources are listed here.

There may be quite a few books out there; But usually they are little more than a slighty obfuscated excerpt of the reference manual with a few examples added. But then, you might get lucky...  Wink/being sarcastic

Still, the reference has all the information you really need. If you don´t understand something specific, just ask.


May the source be with you!  Big thumbs up
 
flyf15
Topic Author
Posts: 6633
Joined: Tue May 18, 1999 11:10 am

RE: Assembly Language Programming

Wed Jan 28, 2004 10:26 am

I suppose my main problem currently is that all I can find assumes I already know something. I'm still figuring out the basics...what registers are, how memory works, what an instruction is, etc. I'm pretty good at C++ though, so I do have a good idea of whow a program is constructed and all (variables, comparisons, operations, ....), but thats about it.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Flyf15

Wed Jan 28, 2004 10:50 am

The essential difference is that assembly code only consists of a list of sequentially executed operations (at least for the 68K) which can read, write or modify either registers or memory or both.

There are no high-level constructs like "while" or "for"; Instead, conditional branch instructions check the condition code flags set by previous instructions and branch to the indicated target address (or not, depending on whether the condition is met).

The concept of condition codes is very different to the usual high-level boolean expressions; But a compiler will just convert the expression into some operations which record their results in the condition codes, followed by one or more conditional branch instructions which test those condition codes.

Instead of a theoretically unlimited number of local variables you´ve got the CPU registers; With the 68K, it´s also very simple to implement additional local variables through stack-relative addressing.

Just look into the reference manual; You´ll find that you can still use quite a bit of your existing knowledge.

And one more thing: While you may have learned previously that "goto"s are to be avoided at all cost, in assembly code they are essential and just need to be handled properly.  Wink/being sarcastic

And another thing: Do yourself a favour and write documentation wherever possible!!! Not so much about the "what", but about the "why". In whatever language you´re writing your code, but especially in assembly code you´ll shoot yourself into every conceivable body part if you´re cutting corners on the documentation.

And still another: Use the debugger to trace your code; It´ll help you understand what´s really going on. You´ll see directly which registers and memory locations are modified by each instruction and where your code may do things you might not have intended.
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 11:11 am

Assembler can be quite fun. Back in University, we had this little game we like to play on our professors and that was to write the most obfuscated assembler code possible. The wonders I use to write with the text editor macro functions and having the program rewriting the op-codes dynamically into memory... I lost a couple of points for the style, but it worked and I got an A (actually A- for the 16-bits assembler course).
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Qb001

Wed Jan 28, 2004 11:26 am

Yeah, there´s almost no limit to the dirty tricks you can employ in machine code...  Big grin

However it´s also possible to write very well-structured and reliable code... Just for the record...  Wink/being sarcastic

Dirty tricks have that annoying habit of turning against their authors; Self-modifying code can get you in hell as soon as you´ve got a code prefetch queue in your CPU (or a real cache). Weird problems of all kinds will arise if you don´t know very, very well what you´re doing...
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 11:47 am

Self-modifying code can get you in hell as soon as you´ve got a code prefetch queue in your CPU

As far as I remember, the 68000 does not fetch code. I think it was introduced in later version, 68020 and up. But I may be wrong.

Then again, I'm trying to figure out what can go wrong with prefetch code and self-modifying code. I guess you're saying that the processor could have begun to fetch an op-code just before it is modified, but then it's too late and the rest of the code "assumes" it was modified, but was not and then crash!

I don't see it, because, at least the way I use to do it, the code change would take place just before an unconditional branch to a calling address.

Basically, it was:
- Do some stuff
- Program meets a condition that requires code change
- Branch to routine to execute code change
- Change code into memory
- Branch back
- and so on.

Maybe if the program is subjected to interrupts, that could be a different ball game.
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Qb001

Wed Jan 28, 2004 12:00 pm

Qb001: As far as I remember, the 68000 does not fetch code. I think it was introduced in later version, 68020 and up. But I may be wrong.

The 68000 does no major prefetch, indeed (maybe one or two instructions); But the "bigger" variants have actual caches which would need to be synchronized before jumping into the modified code. With a prefetch queue, you´d need to delay the jump for as many instructions as necessary to clear out any "old" code first, as you suspected...

When you´re doing the proper synchronisation, it´s even "legal" to use self-modifying code; But as I said: You need to know very well what you´re doing; Otherwise, it´s a case of sheer luck (or lack thereof).  Wink/being sarcastic


Qb001: Maybe if the program is subjected to interrupts, that could be a different ball game.

Indeed... An interrupt can "sometimes" clear out the instruction queue or the cache for you at the right time before the new code is being fetched; But on the other hand, modifying the interrupt code while the interrupt is "hot" is another fine way of shooting yourself in the foot. Kind of like changing a valve while the motor is running... Big grin
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 12:11 pm

With a prefetch queue, you´d need to delay the jump for as many instructions as necessary to clear out any "old" code first, as you suspected...

That's the part I don't get.

My understanding of fetching includes a mecanism to "de-fetch" in case an instruction is not to be executed. Think of all the conditional branches for instance that have to be de-fetched.

Also, it explains why this fetching technique was not as performant as was thought in the first place, essentially because 40% of any assembly code is made of conditional branches, which means that the processor keeps fetching and de-fetching a whole lot of instructions.

And it also explains why the latest Pentium processors have this "branch prediction mecanism", whose role is to try and predict if a branch will be executed or not.
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Qb001

Wed Jan 28, 2004 12:43 pm

Qb001: My understanding of fetching includes a mecanism to "de-fetch" in case an instruction is not to be executed. Think of all the conditional branches for instance that have to be de-fetched.

That is basically correct...

Qb001: And it also explains why the latest Pentium processors have this "branch prediction mecanism", whose role is to try and predict if a branch will be executed or not.

Correct - although this mechanism has been used for almost every "big" CPU by now, since it helps boosting clock frequencies with longer prefetch, decode and execution queues. The 80x86 family suffers from the longest queues by far due to its completely braindamaged base concept which is still being dragged along at all cost (and with progressively diminishing returns).

When the prediction mechanism fails to predict a conditional branch properly, the entire rest of the queue will have to be purged - which in modern CPUs means that some of these instructions may even have begun executing internally so this is quite "expensive" with a long queue and the quality of the branch prediction becomes crucial to the resulting overall performance.

Back to self-modifying code: In order to make it work, you´d need to make sure the modified instruction hasn´t been fetched already when the modifying instruction is being completed; Explicit synchronisation by specialized instructions is the cleanest way to prevent that from happening (and when you´re dealing with a cache, you´ve got no other choice); Merely "stuffing the pipeline" with as many instructions as necessary to keep the distance is a "hack" that may or may not work, depending on the specific CPU variant you´re dealing with... (execute your code on a new CPU with a longer queue than your code expects and you´re screwed again!)

Caches are especially tricky as most modern CPUs have separate data and instruction caches; Your modifying write operation will go into the data cache, but the instructions will be fetched through the instruction cache; This means you may need to do the following:

a) write your modified code (this will actually change the data cache and may not be visible in main memory immediately)
b) "flush" the data cache so it´s actually written to main memory (that may not happen immediately to save bandwidth)
c) "purge" the instruction cache so it won´t "remember" the old incarnation of the newly modified code
d) purge the prefetch queue (if that isn´t done implicitly by purging the i-cache)
e) jump to the modified code (will force the i-cache to read from main memory, then start fetching the new code from the i-cache)

The actual topology of your CPU will determine which of the above steps are necessary; Some operating systems will also protect code memory from modifying data access in order to keep it interesting...  Wink/being sarcastic


With all of the above it becomes clearer why in most cases self-modifying code can´t be used to improve execution efficiency: It requires far too "costly" operations to make it worthwhile in almost every case except on "smaller" CPUs without queues or caches.
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 1:06 pm

With all of the above it becomes clearer why in most cases self-modifying code can´t be used to improve execution efficiency: It requires far too "costly" operations to make it worthwhile in almost every case except on "smaller" CPUs without queues or caches.

Ahhh! You're taking all the fun out of it!

So, still having fun with the pseudo-20 bits address bus of the 80x86 family???
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Qb001

Wed Jan 28, 2004 1:15 pm

I don´t see what fun would be there to be had with that 80x86 junk. I avoid it like the plague!  Angry

I had done some extensive and complex stuff on the 68K several years ago. These days I´m actually doing some assembly stuff again, but for a smaller controller. Besides that, it´s C++, Perl, PHP and a few of my own languages for various projects. Keeps those grey cells alive...  Big thumbs up

Who knows, maybe I´ll poke the PowerPC G5s in my machine natively, some day. Just for fun...  Wink/being sarcastic
 
Qb001
Posts: 1923
Joined: Fri Apr 28, 2000 12:42 am

RE: Assembly Language Programming

Wed Jan 28, 2004 1:32 pm

Good luck with the PowerPc.

Personnaly, I have moved on to other stuff. Mostly some techniques dubbed AI (but aren't really AI), such as fuzzy logic or genetic programming. I'll have to try something with neural networks someday.

I read yesterday that some guys have solved the Kepler conjecture. I want to try something with that and genetic programming; it should be fun.
Never let the facts get in the way of a good theory.
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Qb001

Wed Jan 28, 2004 1:36 pm

Yeah, doing a bit more pure research could be fun... But at this time, I need to get things working properly, first.

Good luck!
 
sccutler
Posts: 5842
Joined: Thu Jan 27, 2000 12:16 pm

RE: Assembly Language Programming

Wed Jan 28, 2004 1:55 pm

Oy! I used to do assembler-level coding for VAX and PDP-11s (DEC).

I am so OLD!
...three miles from BRONS, clear for the ILS one five approach...
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Sccutler

Wed Jan 28, 2004 2:03 pm

No shame in that!  Big thumbs up
(At least I still know what you´re talking aboutBig grin)
 
bobrayner
Posts: 2038
Joined: Sun Apr 27, 2003 8:03 am

RE: Assembly Language Programming

Wed Jan 28, 2004 8:03 pm

Oi! Don't criticise the 80x86... I used to be a 486 floating-point fiend.  Smile/happy/getting dizzy
Cunning linguist
 
Klaus
Posts: 21642
Joined: Wed Jul 11, 2001 7:41 am

Bobrayner

Thu Jan 29, 2004 4:07 am

Well, you´ll certainly deserve a medal for your endurance. Maybe even a purple heart.  Wink/being sarcastic

The x86 concepts are so harebrained and ill-conceived that it´s difficult to believe someone did it on purpose.

It must have been a fiendish plot of a few Intel engineers to make the 8086 extension of the 8080 so obviously unusable that management just had to reject that warmed-over patch to an antique architecture and go for a completely new one instead.

But as evil plots go, management just wouldn´t recognize the trap and just went "Um, okay... let´s build it!".

I know this is not the real history; But it´s still hard to believe.  Wink/being sarcastic

And as the generally failed "Itanic" shows, they haven´t learned a thing since then. Excellent manufacturing - dismal conceptual work.

Who is online

Users browsing this forum: akiss20, art, Google Adsense [Bot], lentokone, luckyone, StarAC17, T18, Tvilum and 58 guests

Popular Searches On Airliners.net

Top Photos of Last:   24 Hours  •  48 Hours  •  7 Days  •  30 Days  •  180 Days  •  365 Days  •  All Time

Military Aircraft Every type from fighters to helicopters from air forces around the globe

Classic Airliners Props and jets from the good old days

Flight Decks Views from inside the cockpit

Aircraft Cabins Passenger cabin shots showing seat arrangements as well as cargo aircraft interior

Cargo Aircraft Pictures of great freighter aircraft

Government Aircraft Aircraft flying government officials

Helicopters Our large helicopter section. Both military and civil versions

Blimps / Airships Everything from the Goodyear blimp to the Zeppelin

Night Photos Beautiful shots taken while the sun is below the horizon

Accidents Accident, incident and crash related photos

Air to Air Photos taken by airborne photographers of airborne aircraft

Special Paint Schemes Aircraft painted in beautiful and original liveries

Airport Overviews Airport overviews from the air or ground

Tails and Winglets Tail and Winglet closeups with beautiful airline logos