21 Jun
2004
21 Jun
'04
6:05 p.m.
It was thus said that the Great Fred Cisin once stated:
I need to make some decisions about some of the content.
Should I include discussion of the .Net IL assembler?
How much on other kinds of processors? (RISC)
How much time should I spend on interrupt handlers, v
file handling?
How much time should I spend on coupling assembly language
subroutines with high level languages?
How much on using assembly language knowledge to debug
high level language problems?
Should I get into writing assembly language stuff that
runs as real Windoze applications, or stick to DOS based stuff?
How much time do you have? From my experience (not in teaching, but in
sitting in several Assembly classes from college) that not many students
"get" it. Perhaps part of that is due to the insturctor (in my case,
spending almost a month covering DEBUG along with simple 8088 instructions)
and perhaps part of that is the strangeness of the language (compared to
higher level languages).
Several of your suggestions could be lumped into a single heading:
calling other APIs. File handling? Calling Windows APIs? Similar stuff
really, just sticking the data in the appropriate place, and transfering
control to the appropriate routine (CALL, INT, SYSCALL, etc).
On making a real Windows application, most of the code will be:
push 0
push SOMECRYPTICVALUE
lea eax,[ebp + localvar]
push eax
lea eax,[ebx + structoffset]
push eax
push SOMEVALUE
push YETANOTHERVALUE
push ebx
mov eax,[ebp + localvar]
mov eax,[eax + structoffset]
push eax
call _Win32DoSomeThingMystic
Just to make a single API call. DOS would be eaiser to program, but
really, how much modern DOS development is being done nowadays? Interrupt
handling is interesting, but again, how much time do you have?
-spc (I might suggest writing code for a virtual VAX ... )