Re: Accessing Command-line text


Wannabee skrev:

Stack-pollution as 'the better choice' ?
PROC belongs to HLL (give the compiler the chance for different CPUs).

I mean that in the sense that for a one time call, to a routine, or a call
that happens very rarly, poluting the stack as you call it, doesnt seem to
me extremly hurtful. Maybe you could show it by some practical example?

Remember our game with WINPROC,
any PROC in general destroys the (CPU-designed) order on stack-contents.
So we had to fool around with the 'return' to be the last 'pushed' when
the code reaches the last return (this was a jump in our case).

Ie: we like to pass on three arguments:
___________
push arg1
push arg2
push arg3
call TEST ;not to forget to define/design TEST for three params
cmp eax true
je...
____
TEST: ;PROC
; most programmers use push epb |mov epb esp here ;just one push more
mov eax[esp+0c] ;arg1
mov ecx[esp+08] ;arg2
mov edx[esp+04] ;arg3
....
cmp ecx,eax
mov eax true
jnz L1>
mov eax false
L1:
ret 0c
_____________
now 'my' way:

mov eax,arg1
mov ecx,arg2
mov edx,arg3
call TEST
jz ...
____
TEST: ;routine
....
cmp ecx,eax
ret ;no stack adjustment required
______



With ASM I may only see few advantage for temporary buffers on stack,
as every L1-cache-line used by stack is lost for code.

I did not know. But what does it mean. It cannot mean what I think it
means? My new pc has 1 mega of L1 cache.

I wont believe that. I'm very happy with my 64 KB L1 (AMD64),
my K7 got just 8 KB and this were 128 cache-lines, 64-bytes each.
L1-cache is part of the CPU (means as fast as the register-space),
L2-cache is a faster than normal RAM, external memory-chip, which
may be up to a few MBs (expensive memory).

I read somewhere that the stack is usually in the cache most of the time,
so reading and writing to it, is not bad (it said).

Yes, as long you can keep stack and code in the cache at all.
Every 'new'(not cached yet) access will result in a fetch-cycle
which needs time and overwrites least used cache lines.

and sometimes in my asm, all registers are already busy,
so then using proc sometimes simplify things.

Sure, thats what PUSH/POP is made for:

pushad
mov anyreg,anyval
....
popad

:):)

But, I guess we are speaking of two different worlds.

Too many Delphy? :)

And also, I still owe to force myself at really understanding this stuff.
btw, does every taskswitch clears the cache, or just the part of it which
is in use?
I mean, that which will be used by the new task? So that some of the
data in the cache is available also after the taskswitch?

Nothing becomes cleared anyway, but if new pages or another stack are
accessed then you can be sure about new cache-burst-reads.


btw. Here is some code I just wrote.

I stored it in my ROSASM-folder to look at it later in more detail.

At a first glance it uses a lot of API.. (can't tell about timing)

The complete process, for a single 180radius circle, takes about 8 million
cycles.
(replacing polygon with Polyline does not change anything).

(thats 2 seconds on an XT :)), and about 4 milliseconds on my AMD 64.
I havent established yet what part of this time is from the API calls as
the calls
are intertwined, but tracing the circle takes about 1743-2200 cycles.
So I guess most of it is API suck.
(not that SetWindowRgn is not included in the timings, nor the loading of
the bitmap).

Some API is in this case needed. the asm creates a pointlist that is used
to create a region, and that region is then used as the "form" of the
window. (a custom non rectangular window). I use the beginpath and
endpath, so I do not have to create all the rectangles needed for creating
the region. (A region, inside, is an array of rectangles). But while
reading your reply I have an idea that it could not be that hard todo. To
avoid the beginpath and endpath brackets, and the call to Polygon, and the
pathtoregion call - I could myself use the pointlist at creating a set of
rectangles (must be rectangles) that would fit perfectly into the figure.
I could then call to CreateRgnIndirectly, and then later to SetWindowRgn.
But those two are absolutly needed, unless you have infoes on how to
bypass them.

Why do you need a set of rectangles?
And whatfor you need SetWindowRegion? For the Mouse-rectangle?

I don't know if windoze can use a polygon for mouse-rectangles,
Let Windoze have it rectangular and filter it off on your own?

Isn't it enough to have the shape as a Y-orderd(line) array of dots?
it would make fill/compare (inner and outer) and polygon-draw easy.


But how do you find the smallest set of rectangles to completly fill the
(any) form?

The smallest set? Just count the lines.

Wouldn't a line by line tracer (transparent "start X-count" @ line-Y)
already produce an ordered list of dot-coordinates for the
first half and a following reversed ("trail X-count" @ line-Y, lines
backwards now) add the second half in the correct order ?

Maybe. I dont understand exactly what you mean. But what you say sound a
bit like my first try, which was to skip transparent pixels, and record
the first pixel that was not, then skip until next transparent pixel, and
record the boundery pixel. This gave me all the points in the figure(s),
but not ordered. (The figure may be very complex, including _any_ 2d
form). And order may mean in a circle, or in a bumby road.

Reserve an array (2*number of lines),(2 entries)

Loop Y (start with top line, until last line)
Loop X (from left to right)
scan for first not transparent(-1) and store pos at line(Y)(1)
next X
next Y
; now you got Y(count) X-entries for the shape's left-side
Loop Y (start with last line, until top line yet)
Loop X (from right to left yet)
scan for first not transparent(+1) and store pos at line(Y)(2)
next X
next Y
; done: all dots on the right side are known yet
1. you have all surrounding dots correct ordered for polygon-draw
2. you have two sets of points for (fast)horizontal line draw
the first half Y(1) are start-points, while second Y(2) are end-points,
the offset between the two is just 'number of lines'.


I assume winAPI polygon needs an array of consecutive X,Y pairs :)

Actually, i think yes. At least i did not get the correct REGION from
using those points.
- but you gave me some ideas.

Good, and good luck on it!
__
wolfgang



.

Relevant Pages

  • Re: further optimizations
    ... mov al B$edx;ok ... The users stack is not affected with this, ... but everything below ESP is never usable anyway... ... It had reprogrammed what you call IDT (interrupt table?) and after ...
    (alt.lang.asm)
  • Re: ml64, PROC and parameters
    ... _test_nested creates 98h bytes of stack space for the sake of the exercise. ... You should push on the stack only the non-parameter register. ... The first 4 parameters are in registers rcx, rdx, r8, r9. ... mov,rcx ...
    (microsoft.public.development.device.drivers)
  • Re: SharedSound information?
    ... compiled with stack checks switched off (which means you need to ... Isn't the SharedSound "callback" type handler something similar? ... MOV v3,lr; preserve link register of SVC-mode foreground process ... preserve two words at base of SVC stack in v1,v2 ...
    (comp.sys.acorn.programmer)
  • Re: Program abnormally terminates
    ... Your original post indicated that the code was failing at that point - "mov dl, ... In real mode, any interrupts that occur use your stack, in addition to any use you make of it - which is already enough to "blow the stack". ... something, and referring to it by that, rather than just putting it first in the segment and assuming offset 0. ...
    (alt.lang.asm)
  • Re: ml64, PROC and parameters
    ... _test_nested creates 98h bytes of stack space for the sake of the exercise. ... You should push on the stack only the non-parameter register. ... The first 4 parameters are in registers rcx, rdx, r8, r9. ... mov,rcx ...
    (microsoft.public.development.device.drivers)