Re: Jort programs, was Jit Implementation

Robert A Duff <>
Sun, 21 Mar 2010 13:02:40 -0400

          From comp.compilers

Related articles
Jit Implementation (Philip Herron) (2010-03-18)
Re: Jit Implementation (bartc) (2010-03-20)
Re: Jort programs, was Jit Implementation (Robert A Duff) (2010-03-21)
| List of all articles for this month |

From: Robert A Duff <>
Newsgroups: comp.compilers
Date: Sun, 21 Mar 2010 13:02:40 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 10-03-054 10-03-060
Keywords: history, code, performance
Posted-Date: 21 Mar 2010 14:21:42 EDT

"bartc" <> writes:

> I started off with experiments such as the following (but note that as you
> appear to be on something like Linux, malloc() memory may possibly not be
> executable, as the moderator notes), for the x86:

You can use mmap on Linux or VirtualAlloc on windows to control this.

>> [... on recent x86
>> where data pages are usually marked no-execute. -John]
> Fortunately that doesn't seem the case with XP and Vista at least.

It's an option. The default for this option depends on the
version of the OS. It also depends on the hardware (note
"recent" in John's comment).

> You might also want to look at mainframe sort programs. Since the mid
> 1960s (maybe earlier) they've generated the code for the inner comparison
> loop, then run the linker and loader to bring it into RAM, then did the sort.
> -John]

Can you please explain that in more detail? I'm not sure I can
picture how this would work, or what the benefit would be, for the
sorting case.

- Bob

[Before everyone used databases, sorting was the largest single
application on mainframes, and its performance was a big deal. (Still
is, I suppose). When you run the sort program, you tell it what the
sort keys are, e.g., bytes 1-4 as packed decimal, then 10-20 as a
character string, reverse order, etc. Rather than reinterpreting the
sort instructions on each record comparison, it compiles them into a
comparison routine that does your particular comparison with inline
code. Running it through the linker before it's loaded also lets you
specify exit routines, user code to pre- or post-process records. In
the 1960s, CPUs were slow enough that this could make the difference
between running the disk or tape drives at full speed or not. A
program called syncsort was the first plug-compatible software, took
the same commands as IBM's sort and ran a lot faster, leading to a
many year war of attrition. As someone else noted, IBM cheated by
adding microcoded instructions to build a heap, which sped up heapsort
and merging. For the very lengthy details, search for DFSORT, the
version of the sort program that runs on current mainframes. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.