Friday, April 25, 2008

Small gains

My explorations in the the explanation of video hardware and its operation today were uninspiring, especially since my principal source is seriously outdated. I use it because I want to learn the basics, the older way, in order to see how things have changed or improved.
I did a little more digging into the BIOS. I'd written down a number of the interrupt vectors, and in the process of checking them over, I found that several of them had changed: that is, there were different values in the segment part of the address. I'm not sure what the pattern is. I haven't actually tried disassembling any of them yet, although I may get around to doing that.
I did a little more organization of my notes on assembler syntax and the operations used by the assembler; Directives including symbol definition (the equates, giving names to constants ) and data definition are getting attention. Assembly language devotes more resources to the to the size of its variable than their contents, which are left up to the programmer. As far as assembly instructions I am considering mostly (unsigned, single byte or word) addition, and I'm trying to get a better handle on the various addressing modes used by the instructions. I'm also starting to work on the unconditional and conditional jumps and the call instructions.
I touched only lightly on Basic programming, with a look at the assignment (let) statement.
In C programming, I made little progress in any any one area, but more significant progress in others. The distinction between integer and floating point types is significant, again with most of the emphasis given to the integer types. Well. I'd like to have a better look at floating point arithmetic, but it's not really critical at the moment.
I also gathered some information on the phases of programming design. In the middle, implement (build) or coding stage, I sorted these out into comments; the use of descriptive names for variables and routines, and the formatting of programs, such as indentation and spacing.
I finally decided to group the execution of the program with the last phase: testing and maintenance. This is because in translated language, the assembler and compiler usually turn up a batch of syntax errors, which must be fixed. Then there are linker errors, and finally the logical errors; in which the computer finally does exactly what you told it to do, which is not necessarily the same as what you meant to tell it to do. Testing to uncover hidden bugs is a more advanced process.

I thought I'd try to implement the programming cycle for a problem I borrowed from one of my physics texts. If a man runs a four minute mile, what is his average speed in miles per hour and feet per second? The design wasn't hard for such a trivial problem, but exposed a number of difficulties.
First, in the assembler, I didn't have output methods. I know how to print a character or a string, but a number has to be translated to a character or string in order to display it. Second, several assumptions wound up being hard-coded into the program. I need to go back and document these before I do an updated version.
Methods for doing output are part of the language in BASIC: what was lacking was facilities for defining symbolic constants. Conversion factors "Feet per mile", "minutes per second", Seconds per minute" so I had to use constants.
The version I was best pleased with was the C version. I haven't tried running either the BASIC or the C version of the program yet: I was happy to get through the writing phase.

The answers are 15 mph and 22 ft per second: sure I can do it by hand, but the question is, can I get the computer to do it? Then, for any given distance? Any given time? Distances, time, and speed given in whatever units I like? Then, what if the speed and distance or given, or speed and time? And what if the speed varies? What about other physical quantities,
While the programs may be trivial, they are first steps toward a larger goal. One of the reasons I faltered in my progress in science was that I hated the drudge work of doing conversions between systems of units. If I can get the computer to do it for me, I can go on to more interesting concepts. At least, that's the idea.

No comments: