mov eax, address_of_next_instruction_beyond_jump
jCC procedure_address


ret
procedure_address:
; code for procedure goes here.
jmp eax    

push address_of_next_instruction_beyond_jump
jCC procedure_address


ret
procedure_address:
; code for procedure goes here.
ret    

  push address_of_next_instruction_beyond_jump
  jCC procedure_address
address_of_next_instruction_beyond_jump:
  ;...
  ret
procedure_address:
  ; code for procedure goes here.
  ret    

mov eax, $ + 3 ; there are issues about CS:IP's value at this point..
jCC proc

; do with eax whatever you please. either way it doesn't matter!

ret
proc:
; code goes here..
jmp eax    

                jnCC     @f; note the inverse jump condition
                call     proc
@@:    

;;; Iterate through possible condition codes and define macro with appropriate name

irps CC, a ae b be c e g ge l le o p pe po s z {
        macro call#CC proc \{
        local ..retaddr                 ; double-dot symbol name -- won't break local labels' attachment
                jn#CC    ..retaddr      ; note that we can't use @f/@@ pair as in above
                call     proc
        ..retaddr:                      ; or else we will obscurely redefine @@ on macro expansion
        \}
}

;;; Make sure that funny mnemonics (jnnge e.g.) get their valid equivalents

irps CC, a ae b be c e g ge l le o p s z {
        jnn#CC  equ      j#CC
}

;;; Parity isn't that ^^^ straightforward, handle special case

jnpe    equ     jpo
jnpo    equ     jpe    

damn.. this is the situation I was trying to avoid.. I don't want to type a label everytime.. it's cumbersome and makes the code dirty.

as far as the stack is concerned, it's usage has downsides. what if the function was never called: there is a memory leak in that second example I put up (the one you modified), since the stack will be modified, but never restored!

the register-style jumps have the advantage of their values being tossed when they're not used as well as when they are. personally, I think modifying the original jump condition so it jumps over a "call proc" on failure is far simpler than anything that employs the stack for this type of case. in the end, the stack example was an error on my part to even mention!

so were back to register usage, does anyone know of a way to avoid having to do this:

Code:

mov eax, $ + 3 ; there are issues about CS:IP's value at this point..
jCC proc

; do with eax whatever you please. either way it doesn't matter!

ret
proc:
; code goes here..
jmp eax    

virtual at $
  instruction
size = $ - $$
end virtual    

irp cc,c,z,e,s,a,b,g,l,ae,be,ge,le,o,p,pe,nc,nz,ne,ns,na,nb,ng,nl,nae,nbe,nge,nle,no,np,po {
 macro call#cc dest \{
         \local .i,.j,i
         .i=$
            j#cc .j
             call dest
       .j=$
            load i from .i
              store (i xor 1) at .i
       \}
}    

mov al, const1
mov ah, const2
; instead of
mov ax, (const2 shl 8) + const1    

macro jCC Which_Register_To_Use, Condition_Code, Function_Address
{
   local return_address
   mov Which_Register_To_Use, return_address
   Condition_Code Function_Address
   return_address:
}

;.
;.
;.

   cmp eax, ebx
   jCC rax, jz, Function    

Returns are predicted by means of a so-called return stack buffer which is a first-in-last-out
buffer that mirrors the return addresses pushed on the stack. A return stack buffer with 16
entries can correctly predict all returns for subroutines at a nesting level up to 16. If the
subroutine nesting level is deeper than the size of the return stack buffer then the failure will
be seen at the outer nesting levels, not the presumably more critical inner nesting levels. A
return stack buffer size of 8 or 16 is therefore sufficient in most cases, except for deeply
nested recursive functions.
The return stack buffer will fail if there is a call without a matching return or a return without
a preceding call. It is therefore important to always match calls and returns. Do not jump out
of a subroutine by any other means than by a RET instruction. And do not use the RET
instruction as an indirect jump. Far calls should be matched with far returns.

But, the function must use jmp rax instead of ret, right? Sorry for re-asking but what is the problem with call instruction (particularly with revolution's callCC)?

macro jCC Which_Register_To_Use, Condition_Code, Function_Address
{
   local return_address
   mov Which_Register_To_Use, return_address
   Condition_Code Function_Address
   return_address:
}

;.
;.
;.

   cmp eax, ebx
   jCC rax, jz, Function
   ; modify rax/eax however you please here, since rax has
   ; already been thrown out/used as a possible return address.
   ret
Function:
;... code
jmp rax    

LocoDelAssembly, how much clocks your highly-optimized always-correctly-predicted-branch code will take before next OS call or context switch? Wink

And you can always save link register (register, holding return address) before nested call, just push it. I can't remember but have a strong feeling that there was an architecture using similar approach...