🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #3409

Re: ABI and growth

#3409
From: John R. Levine
Date: Wed, 17 Jan 1990 02:47
35 lines
2770 bytes
In article <6186@celit.fps.com> hutch@fps.com (Jim Hutchison) writes:
|So here is a thought I was toying with.  How about allowing for library calls
|to trap and re-write there calls as the appropriate instruction?

This sort of thing has been done since time immemorial (which in this
business is about 25 years.)  A few years back I was programming an HP 1000
which is sort of an overgrown 16-bit PDP-8.  When they added floating point
instructions, they made them take their arguments in the place where they'd
be for a call to the floating whatever routine, so the linker could patch the
call into the appropriate instruction.

More recently, PC/IX had a wonderful hack again for floating point.  On the
8088, floating point instructions in the absence of a floating point unit do
nothing in particular, so if you generate in-line instructions and there's no
8087, you lose.  On the other hand, if you do have an 8087, the overhead of
library calls is considerable.  One of the PC/IX kernel guys noticed that
every FP instruction was preceded by a one-byte WAIT instruction, and the
first byte of every floating instruction is in the range D8 through DF.
Instead of generating the WAIT, they generated the first byte of an INT
instruction, so when the program got to that point it would generate an
interrupt on one of the vectors from D8 through DF.  If the machine didn't
have an 8087, it could then pick up the rest of the instruction and emulate
it.  If there was an 8087, it would patch the INT to a WAIT, back up the
instruction pointer, and return.  The first time through any piece of code,
you get an interrupt on each floating instruction but if there's an 8087,
after the first time through any loop the machine ran at full speed.

I don't propose exactly this hack for future ABIs, but there is a lot of
milage to be gained by designing your extensions so that you can patch
call instructions on the fly, getting practically full machine speed while
maintaining binary compatibility with older systems.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."
Technical Details
Message-ID: <1990Jan17.024748.3162@esegue.segue.boston.ma.us>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!samsung!think!snorkelwacker!spdcc!ima!esegue!johnl
References: <6186@celit.fps.com> <2020@crdos1.crd.ge.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!samsung!think!snorkelwacker!spdcc!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: ABI and growth
Keywords: ABI expansion
Message-ID: <1990Jan17.024748.3162@esegue.segue.boston.ma.us>
Date: 17 Jan 90 02:47:48 GMT
References: <6186@celit.fps.com> <2020@crdos1.crd.ge.COM>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 35