ASM

64kb?
with "mov ax, [bx]" what is the max memory i can see using bx? is it 64Kb? ... 4 Oct 2009 06:38

A fast way to xchg with memory
In case someone else finds this useful I found that xchg reg, [mem] was slow. It has to do more work than just exchanging one operand with another. It will also go through a lock protocol process which, while it may not assert lock on the bus if the memory is cached, seems nevertheless to take some time. Loc... 1 Oct 2009 10:32

first argument for a .com program
Somewhere is written about one routine that gets the first argument (if there is someone) on one program .com "Your program must handle seeds in the range of 0 through 100, inclusive. If no seed is given, the seed must default to 0. You may assume that there is a single space character separating any seed number ... 4 Oct 2009 04:31

cld and stc
How are all you? How does it go? If i use one time only the instruction cld in the start of the asm file. org 100h start: cld .... If i never use in the file the instruction stc. Are all lodsb, stosb ecc in that file have "cld diretion"? Thanks ... 2 Oct 2009 05:22

Skybuck's Video Codec update :) (first wheeler solution for cpu and gpu)
Ok the new algorithm for wheeler decoding is sound/correct. For now I designed a sequantial version which uses markings to indicate what happens to certain sections of the wheeler. The algorithm is based on my old idea of processing sections in parallel and extending/moving them. For parallel execution thi... 26 Sep 2009 16:52

Skybuck's Video Codec update :)
Hmm good times for me... Yesterday I had an idea for parallel huffman... Today I have an idea for parallel wheeler... I think I now understand how to do parallel wheeler... it requires using a little bit of extra space per cell... That's all I am gonna say about it for now. I am going to work out this ... 25 Sep 2009 23:06

How to get the first argument in .com file?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ? | | | | | + + + + + +--+--+--+--+--+ +--+--+--+ +--+--+ + + +--+--+ +--+--+ + | | | | | | | | | | | | | | | | ... 29 Sep 2009 17:31

ok, "other" Win64 / Linux x86-64 glue options...
so, here is what options I have: "unstable transfer thunks", which could benefit function pointers, but are not otherwise desirable. as noted, this was the idea from the prior thread of making function pointers which auto-detect the caller and hash the results. not doing anything of the sort, but this is sor... 26 Sep 2009 03:45

"unstable" transfer thunk
> how about all non-native function pointers are essentially "wrapped" with an "unstable" wrapper, which rather than simply calling the function (or even simply converting arguments), will attempt to determine the calling convention of the caller, and handle as appropriate. Just mandate the correct calli... 29 Sep 2009 14:08

hmm: "unstable" transfer thunk
well, here is the issue: the same code may be compiled and run on both Windows and Linux, and it was my consideration to use Win64 for both OS's on x86-64... however, the code using Win64 may closely interoperate with code using the SysV/AMD64 calling convention. problem: in not all cases can it be static... 24 Sep 2009 19:31