It says that Jump out of range by 60 bytes
To solve my problem.
Conditional jumps in 8086 Assembly (and most assembly languages) have a limited distance they can jump. In other words, there's too much code between your jump instruction and the destination (in this case, 60 bytes too many). You didn't post your code so I can't tell you exactly what line to fix, but in general the solution is straightforward.
cmp ax,bx
jnz goHere
; more code is here than the conditional jump will allow
goHere:
; finish up what we were doing
ret
In order to fix the above code, we have to reverse the condition and JMP, since JMP isn't as limited as Jxx is.
cmp ax,bx
jz continue:
jmp goHere
continue:
; finish up what we were doing
ret
goHere:
; now we can get here even though we have too much code for a conditional jump
jmp continue ;this will also have enough range to go there.
There's several ways to re-arrange your code to allow conditional jumps to work as intended, and still get the desired outcome. This is just one technique for it.
Related
I used to be confident of returning to buffer from mini-buffer by just pressing C-g once, until I learned there is a "recursive-edit-mode" inside Emacs Here, which seems to make cancellation action inconsistent. Therefore, I am reading the entire section in hope of finding a more consistent / stateless command to return to mini-buffer.
However, I encountered below problems when following and trying to replicate what the manual says:
Entering Recursive-edit-mode: After "M-x query-replace RET C-r" (in Fundamental-mode), I could not replicate "a pair of square brackets" in mode-line. However, now I DO have to press C-g TWICE to return back to buffer.
Question: Does recursive-edit-mode still have square brackets now? (I am using ver 24.3)
Quitting: The manual directs me to the Quitting section for quitting command. It says Aborting with C-] (abort-recursive-edit) is used to get out of a recursive editing level and cancel the command which invoked it. So I tried it out within "M-x query-replace RET C-r", hoping one C-] will get me out from minibuffer to buffer, but it still takes 2 shots to do that.
Question: Is this normal? If yes, any other command to guarantee command abortion and return to buffer with 1 execution?
Just want to brush frequently used command such as C-g. If made consistent, it may help avoid inputs being eaten (sometimes unnoticed) by the minibuffer due to trapped inside recursive-edit-mode.
Visually confirming point each time inside the buffer makes keyboard input an closed-loop feedback process and thus consumes more attention, though.
You definitely will see square brackets in the mode line for a recursive edit -- but not for a recursive minibuffer.
C-g does act consistently, but it does different things in different contexts (always the same thing for a given context, however). That can be confusing. It can take some getting used to - a bit like it takes getting used to the various behaviors of C-g during Isearch, depending on the current search state.
If you use recursive edits or recursive minibuffers then you need to pay attention to clues wrt the current state/context. Again, this is like learning Isearch. minibuffer-depth-indicate-mode is a must, to provide feedback about what state you are in.
FWIW, beyond minibuffer-depth-indicate-mode, I use a standalone minibuffer frame, and with each recursive edit or recursive minibuffer the background hue is changed slightly, to better indicate the level etc. (The background color changes slightly also for (a) active minibuffer and (b) Isearch. I use library oneonone.el for these things.)
If you don't use a standalone minibuffer frame then you might consider highlighting the square brackets or something else in the mode line, to help you tell where you are at.
C-r during query-replace is a good example of when a recursive edit can be useful. There are a few others. But generally I do not make much use of recursive edits, FWIW. (I do, however, use recursive minibuffers a lot, because I use keys bound in minibuffer maps that do invoke commands that themselves might prompt for input etc.)
Wrt your question about query-replace with C-r: There is no minibuffer involved at all, here. And C-] after C-r does end not only the recursive edit but also the query-replace (whereas C-M-c ends the recursive edit and returns to the query-replace.
FWIW - In Icicles interactions, you might find yourself within any number of recursive minibuffers. (For example, you might use progressive completion to successively narrow the set of completion candidates, and each narrowing opens a recursive minibuffer.)
C-g always aborts the current command, or if there is none then the current minibuffer, and C-] always aborts the current minibuffer. Repeating C-g (or C-]) pops back up the minibuffer chain, a level at a time. But (in Icicles) you can use C-M-S-t (aka C-M-T) to pop directly back to the top level (exit all minibuffers).
Similarly, answering a minibuffer prompt (e.g. hitting RET or using mouse-2 on a candidate in *Completions*) exits the current minibuffer, popping up a level (to the parent minibuffer or to the top level if there is none). (In Icicles RET can optionally put you back at top level.)
Today I was wondering why the GFlags option Stop on hung GUI appears in the Kernel Flags tab of the GFlags user interface. Does the kernel have a GUI which could hang?
So I tried to get some information from Microsoft, but MSDN just says:
The Stop on hung GUI flag appears in GFlags, but it has no effect on Windows.
So I wonder even more: a kernel flag for a kernel which has a GUI, but it's not the Windows kernel?
Although it seems not of practical use, can anyone explain this?
I also tried to get more information from WinDbg .hh !gflag, but it doesn't even give the statement that this won't work on Windows.
Kernel flag indicates flag takes effect immediately without requiring a reboot
Registry flag requires a reboot for the flags to take effect
the kernel does not have any gui that could hang.
the term windows doesnt mean kernel but the gui windows of the running application
check NtSetSystemInformation in your os to understand why 0x8 does not take effect
basically there are a few hardcoded magic numbers inside this api which tests each request for GlobalFlag changes and allows them or disallows them
in xp-sp3 this magic value is 0B2319BF0 so any flag that is < 0x10 will be disallowed
and stop on hung gui is 0x8 so it isnt effective and you cant set this from registry tab
so effectively no way of setting this flag
nt!NtSetSystemInformation+0x193:
80606009 8b03 mov eax,dword ptr [ebx] ds:0023:001285f8=00000008 <---- +shg
8060600b 25f09b31b2 and eax,0B2319BF0h < magic value in nt
80606010 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606013 8b0d6c125580 mov ecx,dword ptr [nt!NtGlobalFlag (8055126c)] ds:0023:8055126c=00000000
80606019 81e10f64ce4d and ecx,4DCE640Fh <--another magic value both these magic values orred together
will be 0xffffffff covers the whole range of flags
8060601f 0bc1 or eax,ecx
80606021 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606024 a36c125580 mov dword ptr [nt!NtGlobalFlag (8055126c)],eax ds:0023:8055126c=00000000
I have set a breakpoint which should print a pointer and then continue, because I don't want to stop there.
bu 410cc8 ".printf \"Class: %08lX Filebuffer: %08X\\n\", eax, edx; g"
The problem with this is now, when I singlestep and such a breakpoint is fired, like here:
1 mov eax, [ebp+var_10]
2 lea edx, [eax+2Ch]
3 mov eax, ebx
4 call ReadFileFkt_2
5 mov eax, [ebp+var_10]
So when I'm on line 4, and step over it, the above breakpoint is fired and the message is printed. But then the debugger never comes back, because in the breakpoint I use "g" to continue, so the single step is erased.
If I don't use "g" then the breakpoint will be hit and the debugger stops there, so I have to track my way back to where I came from. Of course I could set a breakpoint after the call, but then I would have to remember doing this in other parts of the code as well, because I don't know when the breakpoint is fired from deep within some calling hierarchy.
Use 'gc' (go from conditional breakpoint) instead of 'g' (go).
This command was designed specifically for the problem you have.
Can anyone advise how I can move forward (or back) by n commas in emacs?
I am trying to navigate my way through a CSV file
I am aware I can do something like:
C-u 100 M-f
but being able to do something more reg-exp like specifically on commas would be more accurate
The other thing I tried was combining C-u # and C-s , but that didn't work
It will with a keyboard macro, which you can define interactively.
C-x( -- start recording
C-s,RET -- search for a comma (the RET is important; see below)
C-x) -- stop recording
You can now execute that macro again with C-xe (and then just e for continued single repetitions), or use a prefix argument to repeat it a given number of times:
C-u 100 C-xe
Keyboard macros are tremendously useful, and can be easily bound to keys, or even added to your .emacs file in elisp form if you want to keep one for future use. See the manual for details.
edit:
More seamlessly for ad-hoc macros, you can supply the prefix argument when you stop the recording to get exactly that many repetitions, including the one used to record it:
C-x(C-s,RETC-u 100 C-x)
I was seeing some unexpected behaviour with that sequence before I added the RET to explicitly invoke isearch-exit before stopping recording. It behaved as if it was only recording and repeating the comma key (leading to the comma being inserted many times instead of being searched for many times).
Using edit-last-kbd-macro after recording, I could see there was a quirk when using isearch in a macro, such that the C-x typed when stopping the recording is actually included in the macro definition, which was presumably causing the problem for this particular method of invocation. Similarly with the alternate F3 and F4 bindings (in that case, F4 ends up in the definition). I don't know whether this is a bug or a feature, but apparently it pays to exit the isearch before stopping the macro recording!
p.s. Although the two sets of macro recording bindings aren't identical in all respects, everything here also works with F3 and F4, so for this example you could slightly more concisely use F3C-s,RETC-u 100 F4
With
iy-go-to-char you
can do M-3C-cf, to go to
the third comma.
Use CSV mode which will give you convenient functions to do what you want and more
You could record a macro with C-u C-u M-f or C-u C-u C-f and use that. If it's infrequently used, record it using PF3 and play it back by pressing PF4.
I'm writing a compiler for a course. I've run into some optimization issues of which I am unsure how to handle optimally. Suppose there is a while loop from the input language that uses N local variables which must be held in registers (or should be, for fast computations). Suppose N > K, the number of registers. There is a chance of the conditional register being changed near the end of the while loop.
For example, suppose the register for x (let's say %eax on i386) was determined before the following statement:
while ( x ) { x = x - 1 ; /* more statements */ }
In the more statements code, it is possible for x to be spilled back onto the stack. When the code jumps back to the beginning of the while loop to re-evaluate x, it will try to use %eax--but this may not even be holding the value of x now. So we could have something like
movl -8(%ebp), %eax # eax <- x
.... # do stuff but let x stay in %eax
_LOOP1: cmpl $0, %eax
....
movl -12(%ebp), %eax #eax now holds something else
....
jmp _LOOP1
One solution I'm using is to force the code to spill all modified registers before the while statement (so the registers are viewed as empty from the code generator's perspective). After the label for the while loop, the code has to load everything into a register as necessary.
My solution is something like this:
movl -8(%ebp), %eax # eax <- x
.... # do stuff but let x stay in %eax
movl %eax, -8(%ebp) # spilling and clearing all registers
_LOOP1: movl -8(%ebp), %eax # get a register for x again
cmpl $0, %eax
....
movl -12(%ebp), %eax # eax now holds something else
....
movl %eax, -8(%ebp) # spill to prevent overwrite
jmp _LOOP1
It seems like my solution is a little extraneous or unnecessary. Is there some general optimization trick I am forgetting here?
EDIT: I would also like to note something similar occurs for conditionals such as if and if else. This occurs for them because a register may be allocated for a variable inside the block for the conditional, but the code generator assumes it was moved in there for everything else after. I have almost the same approach for dealing with that case.
The general technique you're looking for here is usually called "live range splitting". A Google Search for that term will give you pointers to a bunch of different papers. Basically the idea is that you want to split a single variable (x in your example) into multiple variables with disjoint live ranges each of which gets copied to the next at the splitting point. So you'd have x.0 before the loop, which is copied into x.1 just before the while and used as that in the loop. Then right after the loop, you'd copy x.1 into x.2 and use that after the loop. Each of the split vars would be potentially allocated to a different register (or stack slot).
There are a lot of tradeoffs here -- too much splitting leads to (many) more variables in the code, making register allocation much slower, and potentially leading to unnecessary copies.