From: steck@ccs.northeastern.edu (Paul Steckler)
Newsgroups: comp.os.os2.misc,comp.os.os2.advocacy
Subject: Re: What is thunking?
Keywords: thunking
Date: 28 Sep 92 02:07:16 GMT
Organization: Comp. Sci. @ NU

In article <1992Sep26.85832.21656@ms.uky.edu> jedwards@ms.uky.edu (Jonathan Edwards) writes:
>gonzaled@ucsu.Colorado.EDU (LGV/MC) writes:
>
>>I've heard this term, "thunking," used at least a couple of times in the
>>OS/2 newsgroups and would like to see a detailed explanation of what exactly
>>thunking is/does.
>>Plus, I'm curious if it's a bad or smart way to do whatever it does.
>
>>So, essentially, what is thunking and does it have merits?
>
>OS/2 2.0 supports both 16-bit and 32-bit code.  The problem that thunking
>solves is allowing 32-bit programs to invoke 16-bit routines.
>
>The Intel x86 architecture is segmented.  A segment is referenced via a 
>selector.  In the 16-bit universe, a segment can be no larger than 64K.
>That limit was increased to 4G when the 386 came along.
>
>OS/2 2.0 uses a single selector to map the flat address space a 32-bit
>module sees.  (This is an oversimplification but the things it ignores
>are not important from the thunking point of view.)  OS/2 2.0 also maps
>the segmented address space a 16-bit module sees on top of the flat
>address by breaking the flat addess space into distinct 64K blocks and
>assigning a single selector to each block.  (There are 8K selectors
>available for this purpose, which is why the application address space
>under OS/2 2.0 is limited to 512M rather than 4G...)
>
>Since the 16-bit and 32-bit address spaces map the same set of virtual
>(linear) addresses, 16-bit code and 32-bit code can share information.
>To do so, however, something must ensure that any 32-bit pointers the
>32-bit code passes to a 16-bit routine are translated to the equivalent
>16-bit segmented pointers along the way.  The code that takes care of
>this is called a thunk.  (The thunk must also handle a number of other
>related tasks made necessary by the x86 architecture, such as changing
>all the segment registers to hold 16-bit selectors rather than 32-bit
>selectors.)  
>
>This scheme imposes additional constraints that a thunk cannot solve.
>For instance, 32-bit code must ensure that any variable it passes to
>16-bit code does not cross a 64K boundary.  (The 16-bit code is  
>probably not expecting to receive an argument that spans segments.)
>
>Thunking is not pretty and it's unfortunate that it's required.  The
>alternative would have been to disallow most 32-bit-to-16-bit interaction.
>This might have been reasonable had 32-bit versions of everything been
>available immediately.  Given that that's not the case (and probably
>couldn't have been), thunking is a reasonable burden (especially since
>most of the work can be done by the compiler if you tell it what
>you're going to do).

A "thunk", generally, is a function or procedure without arguments.
Since it takes no arguments, its utility is that what it does depends 
on the context of its invocation.  It's used to support language
constructs such as lazy evaluation and call-by-name.  

The name is putatively onomatopoetic:  The designers of ALGOL60 claimed 
that such procedures made a "thunk" sound when pushed on the stack.

I don't know the exact mechanism OS/2 uses, but a thunk could
do 16-bit/32-bit conversions depending on context.

-- Paul
-- 
 -----------------------------------------------------------------------
| Paul Steckler                       |  Were I Brittania,              |
| steck@dworkin.ccs.northeastern.edu  |    I'd waive the rules ...      |
 -----------------------------------------------------------------------
Newsgroups: comp.os.os2.misc