lau wrote:
b9 wrote:
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.
i was only writing a verbal description of a process and not trying to write code.
i structured the indenting in an assembler programming style way to help with the concept.
i was not suggesting that to type a program with what i wrote would be able to be executed.
i did not mention "variable constants"
the comments in my description are to say what is being achieved by that line.
the "constant" in both cases is the static value of the perpendicular vector to the line.
if the y line is drawn at x position 100, then 100 is constant.
if the x line is drawn at y position 600, then the y pos is constant and the x variable.
the values of the constants are arbitrary, so i did not include any example constants.
so instead of saying "load screenpos x value constant into reg Y"
i may have said "load 800 into reg Y" (if pixel 800 was the horizontal position of the vertical line)
lau wrote:
Well crafted? Hardly, when it takes quite a time to decipher what is going on.
i agree that if it is hard for others to decipher, it is not good.
but for the CPU , it is a cinch.
lau wrote:
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.
as far as speed of execution, i know that branching is slow, and jumping is even slower.
branches that are not conditionally met are not very taxing however.
but if the condition IS met and the branch is performed then that is where the tax happens.
but if the condition is false, then the cpu just falls through to the next instruction. i know there is some energy consumed in the determination of the condition.
anyway, my sample was not formulated for speed, but for limited cycles of "module" execution.
i thought he was wondering how to draw both lines in the one engine without drawing a null 50 times with the line that is only 25 long.(although that may not be processor hungry because i never tried pushing null values in a speed test).
lau wrote:
as far as functional loops
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).
well it was a simultaneous loop counter and it seemed nifty.
the 25 counter runs out of puff and it's branch conditions all fall away and only the 75 counter uses any real muscle and when they are both equal to 0 then it is finished.
i could ask 2 questions ie: if a=0 and b=0 then finish, but i opted for one question was when a=b then both must be zero, so finish.
the fastest way is to just set the pixels with 25 lines of code for the horizontal line, and 75 lines of code for the y line.
eg
pset(1,100)
pset(2,100)
pset(3,100)
.
.
.
.
pset(25,100)
then follow with the vertical code pixel by pixel.
but that would be ridiculous to write such code for a single screen of 2 lines.
in normal programming, one would never use machine code to code a "one off" thing.
it is small pockets of super fast executable code that uses input that is fed from 4gl programs.
when i wrote functional assembly code (for myself)i did not load hard wired values into registers.
i set up a memory area where all the values were psh'd or pop'd from.
so my code would start with popping the registers from values in memory locations stored there by the mother application.
then they would "psh" into the memory locations, the results after the module had executed.
the scope of his question was a simple one, and i did not perceive it to be asking for optimisation in cpu events, or a fast way to do it.
i saw it as a way he could perform both tasks simultaneously on a simple level.
lau wrote:
and
Errors? Well, for starters, you draw the first pixel twice, which is more wasted time.
that is incorrect. "setx" points to "DRAWX" and sets the first x pixel, and then it decrements the register, so it poists to the next lower adjacent pixel fom the first step.
i did not set x pixel in the SETX tag code. only in DRAWX, which decrements as a matter of course, the x register.
and, as a remainder of the subtraction of that misapprehension, we get one pixel unaccounted for at the other end.
there were 25 iterations, and each "set" was decremented from it's successor.
lau wrote:
You draw neither endpoint of the lines (which is how the original source code shows that it must be done).
well each line was of the correct length and had no duplicate pixels set.
i am not aware whether the 25 pixel wide horizintal line is supposed to intersect the 75 pixel high vertical line. i do not know where there "origins" are. it is just one 25 line and one 75 line.
and the function of the pseudo logic i wrote draws a horizontal line 25 wide and a vertical line 75 high.
that is all that was asked (as far as i remember (i may be back to edit this soon)).
lau wrote:
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.
i know there is only one type of circumstance in which that structure i posted would be valid. but alternative circumstances were not presented in the scope of the question of the original poster's post.
i am not going to code a multi purpose module just to respond to a post.
i know that the structure i proposed is only suitable (or not even) in the circumstance of the posters query.
i reality if i programmed anything like the original question of the poster for money, there would be a number of logic gates that would filter the interpreter through channels of execution that are generic.
whatever, i am waffling and i take your points that you have made to mind.
22 Dec 2008, 8:52 am
