Assembly (Stage 2) -- Assembling the source file e1v1.s

Assembling the code -- e1v1.s

In your working directory, build the file "e1v1.s" with an editor or else click on e1v1.s and download the file into your lab1 directory.

We shall apply the Hope It Works process to the HVZ file. This means that we simply hope that the SDS assembler recognizes most of the original Motorola syntax.

You can assemble the file for later execution by the SDS 68020 simulator by issuing the following command.

as68000 -V 68020 -L -m -o e1v1.o e1v1.s

The "as68000" command will generate

More detailed explanation of the "as68000" options are not necessary at the present moment.


Quick assembly methods

Since I am likely to be re-issuing the assembler and other commands, with all their various quirky options, I like to set up an automated approach. Using this approach all the details are handled automatically once I have worked out what needs to be done. There are a number of approaches to the automation.


NOW "DOIT"

It is recommended that you actually do this exercise before moving on to the next WEB page. Issue the command to assemble the file

as68000 -V68020 -L -m -o t1v1.o t1v1.s

Those students who wish to make use of the Assembler GUI interface build into the SDS toolkit should follow this link to see how to set up this interface. (Note:- using the interface means that you have no choice but to also use the -f assembler option. This option has no effect on this exercise.)

You should be aware that assembler directives and instructions can be manufacturer dependent.This assembler command will not complete and will generate a number of errors, which will be output to the screen. The errors will also be captured in the listing file t1v1.lst.

Try and interpret the error messages in t1v1.lst file yourself before moving on. This will give you some experience before tackling the other laboratories in this "Companion" where you will be working much more on your own.


Get to know the "typical errors" you can make

Industry software engineering standards indicate that the amount of time spent in looking through (reviewing) your code, to catch possible errors when you have just written the code, is 5 to 10 times less than the amount of time you spend finding and debugging errors you left in the code and find when testing the code. The rationale is that

It is useful to become familiar with the errors that YOU typically generate when assembly language coding. You can save a lot of time in the laboratory by performing a quick check of your code (perhaps with a CHECK LIST of your own errors). You can follow this link to find out about some typical errors made when developing assembly language code.



Last modified: July 02, 1996 06:40 PM by M. Smith. Copyright -- M. R. Smith