thunk

(redirected from thunks)
Also found in: Dictionary, Thesaurus.

thunk

[thəŋk]
(computer science)
An additional subprogram created by the compiler to represent the evaluation of the argument of an expression in the call-by-name procedure.

thunk

(programming)
/thuhnk/ 1. "A piece of coding which provides an address", according to P. Z. Ingerman, who invented thunks in 1961 as a way of binding actual parameters to their formal definitions in ALGOL 60 procedure calls. If a procedure is called with an expression in the place of a formal parameter, the compiler generates a thunk which computes the expression and leaves the address of the result in some standard location.

2. The term was later generalised to mean an expression, frozen together with its environment (variable values), for later evaluation if and when needed (similar to a "closure"). The process of unfreezing these thunks is called "forcing".

3. A stubroutine, in an overlay programming environment, that loads and jumps to the correct overlay.

Compare trampoline.

There are a couple of onomatopoeic myths circulating about the origin of this term. The most common is that it is the sound made by data hitting the stack; another holds that the sound is that of the data hitting an accumulator. Yet another suggests that it is the sound of the expression being unfrozen at argument-evaluation time. In fact, according to the inventors, it was coined after they realised (in the wee hours after hours of discussion) that the type of an argument in ALGOL 60 could be figured out in advance with a little compile-time thought, simplifying the evaluation machinery. In other words, it had "already been thought of"; thus it was christened a "thunk", which is "the past tense of "think" at two in the morning".

4. (Microsoft Windows programming) universal thunk, generic thunk, flat thunk.

thunk

In a PC, to execute the instructions required to switch between segmented addressing of memory and flat addressing. A thunk typically occurs when a 16-bit application is running in a 32-bit address space, and its 16-bit segmented address must be converted into a full 32-bit flat address. On the other hand, if a 32-bit program calls a 16-bit DLL, then the thunk is in the opposite direction: from 32 bit to 16 bit.
References in periodicals archive ?
Currently, the compiler is only able to generate thunks for calling nonvirtual class member functions.
In the common case of calling a nonvirtual class member function that does not need any this adjustment, we do not need any thunk.
The thunk needed for calling C: : f is the following short piece of code:
For calling the virtual member function C: :g we need the thunk
If C: : g were inherited from a virtual base class and would require a nonzero offset to be added to this, the thunk would be
Also VB_OFF would be a constant hard-coded into the thunk.
If a member function of the LHS signature does not have the exact same argument and return types as the member function of the RHS signature, however, the compiler needs to generate a new thunk that performs the conversions needed and then branches to the thunk from the RHS signature table.
In the thunk implementation described in Granston and Russo [1991], copying of signature table entries is avoided by having the optr of the LHS signature pointer point to the RHS signature pointer instead of pointing to the object.
Since in our test cases no this adjustment or argument conversion is necessary, there is no thunk for calling a nonvirtual member function.