Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Jit Implementation herron.philip@googlemail.com (Philip Herron) (2010-03-18) |
| Re: Jit Implementation bobduff@shell01.TheWorld.com (Robert A Duff) (2010-03-19) |
| Re: Jit Implementation bartc@freeuk.com (bartc) (2010-03-20) |
| Re: Jit Implementation jgd@cix.compulink.co.uk (2010-03-20) |
| Re: Jit Implementation anton@mips.complang.tuwien.ac.at (2010-03-21) |
| Re: Jit Implementation gah@ugcs.caltech.edu (glen herrmannsfeldt) (2010-03-21) |
| Re: Jit Implementation herron.philip@googlemail.com (Philip Herron) (2010-03-21) |
| Re: Jit Implementation jthorn@astro.indiana-zebra.edu (Jonathan Thornburg \[remove -animal to reply\]) (2010-03-21) |
| Re: Jit Implementation cr88192@hotmail.com (BGB / cr88192) (2010-03-21) |
| Re: Jit Implementation herron.philip@googlemail.com (Philip Herron) (2010-03-21) |
| Re: Jit Implementation barry.j.kelly@gmail.com (Barry Kelly) (2010-03-22) |
| Re: Jit Implementation bartc@freeuk.com (bartc) (2010-03-23) |
| [7 later articles] |
| From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
| Newsgroups: | comp.compilers |
| Date: | Sun, 21 Mar 2010 16:20:25 +0000 (UTC) |
| Organization: | California Institute of Technology, Pasadena |
| References: | 10-03-054 10-03-060 |
| Keywords: | architecture, code, history, comment |
| Posted-Date: | 21 Mar 2010 12:50:53 EDT |
bartc <bartc@freeuk.com> wrote:
(snip)
> [This sounds like a project about a decade ago called slim binaries, which
> shipped programs for a Mac in a compact low-level intermediate code, and
> generated 68K or PPC code as the program was loaded. They claimed that the
> intermediate form was enough smaller than native code that the savings in
> disk access more than made up for the time spent translating.
I have suggested something like that a few times here. With newer
processors, expecially ones like Itanium, expecting the compiler to do
much of the work on generating optimal code sequences, and with a
continual progression of newer processors, it seems to me the only way
software can keep up with the hardware.
> 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]
And when that wasn't enough they went to microcode. I don't know the
story very well, but rumor is that the UPdate Tree (UPT) and Compare
and Form Codeword (CFC) instructions were added to S/370 (or maybe not
until XA/370) to compete with Syncsort. As the story goes, they were
originally not documented such that only IBM could use them in its
sort products. They are now documented, including examples with code
sequences and the register contents going through a sample data set.
Also, the source code for OS/360 SORT/MERGE is available in the
usual OS/360 source code files. (I believe either through Hercules
or cbttape.org.) That is 132621 lines of assembler code. It will
take a little while to find out how it works.
-- glen
[Oh, and of course there's the IBM S/38 and AS/400 where the nominal
machine code is translated at the last minute to the actual machine
code, which let them do vastly different implementations over the
years, but nobody needed to recompile. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.