Assembly Language

Post Reply New Topic

Its also the slowest to code. And hardest to debug. You must learn to comment your asm code heavily! Your teacher did a poor job of that.

No.
http://en.wikipedia.org/wiki/Mode_13h

Also, your pseudocode fails to draw the final dot.

===============



Ah. Yes.

Firstly, you were correct to be concerned about duplicating the loop label, but all that's needed there is to change the name, on the second copy of the loop. You will also want to modify the plain "length" - which I would suggest you replace with separate "width" (as per the original), and "height (75)" for use in the second loop.

Other than those changes, most of the loop, plus its initialisation, needs to be copied. I say "most", because the way the loop operates (adding the "length", then counting back until the original (x,y) has been drawn, means that the "y" is OK at this point. However the "x" will have "overshot", the way the code is written, so needs to be reset. Then the "height" (75) is added to the y-coordinate, and that "y" value is counted back.

As to why your modifications resulted in only a pair of dots (I guess the endpoints of the lines, farthest from the base x,y coordinates?)... I don't know, as you haven't posted what you did.

One approach that may be useful, would be to temporarily remove each of the two loops, in turn, to see if the remaining one works. If they don't, compare them with what you started with, to see what you have altered.

===============

At then end of all the above, technically, you will have one "bug" in the code. Being pedantic, the code will be setting the base (x,y) pixel twice - once at the end of each loop. Depending on your instructor's sense of humour, if he accepts the solution, with the "error", you could point it out to him.

In this instance, redrawing the final dot is almost irrelevant (it does cost 1% in speed terms, which s pretty trivial). However, when you work with more serious graphics, you will need to be careful of such things. E.g. if you were performing a (made up) operation like "increase the brightness at each point by 50%", if this were done twice to the point in the corner, it probably wouldn't look at all right!

I think some of the people here are failing to understand the concept of the exercise.

What this guy needs is to modify the code with the least possible number of changes to do something specific as simply as possible not rewrite the whole thing or use fancy tricks.

Nicely put, Fraya.

Sorry about the last dot. I wrote it in a hurry. As to the wikipedia article, the article is totally wrong. I have coded 320x200x256 color VGA apps many many times. There are NO planes in that mode and one byte is one dot. Once the display is initialized and the palette loaded, its a piece of cake to address it via direct memory accesses. The display takes 320x200 bytes (64,000 bytes) not 256K bytes as the article says. What they may be talking about is SVGA which has as many accessing methods as it did cards.

And yes, you must initialize the palette because not all cards initialize it then same way. If you run on windows, you are running on a VGA card emulator and not directly on real hardware. So there might be default initialization by windows, but not on real DOS.

I've always wanted to learn assembly languages.

At what point in the process did you decide that the code was running under an operating system other than the BIOS?

The clue is in the mentioned "EMU8086". I'm guessing that that emulator comes with some emulation of a BIOS included.

Just a quick note about this.

Modern C compilers are amazingly efficient at optimization. A C programmer can use the key word "register" to make the compiler put a particular variable in a machine register rather than in memory. That has been around since the language was invented in the 70's, but modern compilers go much further and come very close to making direct Assembly coding obsolete.

As far as the most compact code size, this award goes to Forth and not assembly. A Forth program takes about half as much memory as an algorithmically equivalent assembly program. That fact cannot really be disputed. One of the bad things about Forth is that it will run about 10 times slower than an assembly program. Forth is also very counter intuitive and difficult to code.

Given the the fact that program size isn't really that important these days, the fact that Forth is slow and hard to code probably has something to do with its demise.

Hey! You took ALL the words right out of my mouth!

I'll add that ValMikeSmith is "technically" correct, in that anything else can always be disassembled, then "tweaked" a bit, so it is both smaller and faster. (That includes "cheating", with Forth, because you would have to keep the whole Forth system, and just stop mentioning that it was Forth.)

However, without a doubt, handwritten assembly code, other than short, very targeted code, will never be as fast as C (or almost any modern language compiled to machine/assembly code) or small as Forth (especially my 3Kbyte Sinclair Spectrum Forth).

I would suggest changing the psuedo code to use > rather than != for the comparison. The current version will run for a long time if passed a negative length for the line.

I totally agree with the point that most modern compilers will build better code than 99.999% of the people who call themselves programmers/developers who write natively in assembly. I don't buy the arguments that hand-written assembly is faster than not. There are additional compiler tools that will analyze the C code and rearrange the produced assembly code to optimize for target L1 and L2 cache sizes. I can't see a "by-hand" developer doing the same - which means the optimized C would run faster.

In addition, assembly becomes more expensive to use because it can't be ported across hardware. I've seen projects where developers have used very small amounts of assembly - only to have it ripped out because cross-platform development was more important than the developer's ego.

But still, It is a good idea to be familiar with how the machine actually works. That knowledge can help one to code more efficient C. There is also an occasional need to drop into assembly to write processor dependent subroutines. However, I would never use it for an entire program unless I didn't have any other way to do it.

At least if you know how the processor works, then when you're reduced to tracking through what the compiler(s) have made of your intentions to find out how to improve things, you'll have some idea about what's going on.

Back when 8MHz was a fast processor, we could make serious differences by second guessing the compilers, but these days - go for Java and a Hotspot JVM

i programmed when i was a child using an "edtasm" assembler for a trs80 computer.

the example you provide seems like a 1st generation interpreted language (1GL).
if you can set a pixel by a simple x-y coordinate value, then there is some interpretation by the compiler that converts the values to the proper "machine code".

when i programmed in assembly, i had to address the section of memory that housed the screen in a binary way.

screen memory is divided into bytes in an "addressing" sense, and bits in a "setting" sense.

so if you want pixel 1,1 to be lit then you poke a value of 1 into the byte that houses pixel 1,1.

if you want pixel 2,1 to be lit, you poke 2.
if you want pixel 3, then you poke 4.
if you want pixel 7, you poke 64 (00000010)

if you want a horizontal line from pixel 2,1 to pixel 5,1 then you poke 30 into that memory location (01111000).

the calculation of the modulus of the pixel x value as a function of 256 is another issue as the byte address is incremented after each 8 pixels have been set within it.
i used to use "logical right shifts" (LSR's) to roll the 8 and 16 bit registers like a bulldozers track that recirculates endlessly.
so it is like 1 2 4 8 16 32 64 128 1 2 etc....
that is the mechanism that lights up each successive bit in that incremental byte. if it is not a solid line that is needed, then it is like there are missing treads in the bulldozer track.
the y axis was addressed by poking a constant value into each y address.
y addresses were decremented by a value equal to the screen resolution divided by 8.
and the constant value is poked.
to get a single pixel line, you have to use a perfect power of 2 or the value 1.

anyway
if i wanted to draw 2 lines simultaneously with the same general code, i would do the x variable y constant pixels and y variable x constant pixels in separate subroutines.
have the engine of your program delegate with conditions the subroutines that are performed.

i can not write in your language, and i shall not use my even more elemental language to demonstrate an idea (becaue it would not be understood).
i will use a mental code with normal words that approximate the lowness of level of assembly coding.

the forum does not like spaces so i will post an image.


Shot at 2008-12-20

The forum does like spaces.

If you wish to post code, use [code][/code] around it, which will use a fixed width font and leave all formatting to you.

============

PS. Your program draws a diagonal, zig-zag line for a distance of 25 each way, then continues vertical for 50, unless you introduce some way of preserving the initial x, y. Just saying "that has a constant ..." doesn't really help.

thankyou for giving me that information.
when i next post code i will remember it.


you can not say that, since i posted no code as to how the pixel setting is to be achieved.
i was being generic and trying to propose a processional ideology to help him solve the question as to whether he could have an engine that simultaneously solves his 2 simple problems.

the vertical line is straight because the x value is constant.
the horizontal line is straight because the y value is constant

the logical design of the routine is well crafted to perform the task with no useless cycles of execution, and no possibility of an"exception error"

Sorry, but I have to disagree strongly here.

Your code, as shown, does not show the logic of how the magical varible constants are carried over. You cannot have comments in your code that reference values that have never been stored.

Well crafted? Hardly, when it takes quite a time to decipher what is going on.

Useless cycles of execution? It has those in abundance. The one thing processors hate the most is branches - even unconditional ones. Combining two loops together is awful, and results in your code having three conditional branches per cycle. Generally, updating both the loop counter and the coordinate independently is probably wasteful (versus the original code, which clearly compared the updated coordinate to an end value).

Errors? Well, for starters, you draw the first pixel twice, which is more wasted time. You draw neither endpoint of the lines (which is how the original source code shows that it must be done). If the counts in A and B were to start off equal, greater than zero, you would draw nothing but the first point (twice). If Either A or B started off negative, and they were not equal, the code would never complete, until they wrapped round to postive, and back to zero, which would also certainly crash your machine, if the display RAM happened to be memory mapped.

Assembler coding is all in the detail.