"Jeff M." <massung@[EMAIL PROTECTED]
> writes:
>I'm curious (using ITC or DTC) if any implementations have tried
>implementing literals inline with NEXT as opposed to using a word, and
>what the cost trade-off was. For example, I'm thinking something like
>this:
>
>- assume all words are at least 4-byte aligned
>- NEXT checks the LSB @[EMAIL PROTECTED]
[IP], and if set, pushes a literal ([IP] >> 1)
>- otherwise do normal execution of [IP]
....
>NEXT is now slightly larger (perhaps to the point of not being worthy
>of inlining?), and has a compare in there. However, I wonder if (given
>the program), this might be better overall. For example, at what % of
>the code being integer literals would this break even and start
>becoming an optimization or would that never happen?
You would have to compare the cost of the two versions of NEXT with
the cost of LIT (including its NEXT). If plain LIT is as cheap or
cheaper than your enhanced NEXT, then your enhanced NEXT does never
break even. Depending on the CPU, this could easily be the case,
because of branch mispredictions of the conditional branch, and
because you have an additional ****ft where the ordinary LIT doesn't.
Even if this scheme has a break even, it is doubtful that usual
programs reach it. The data at
<http://www.complang.tuwien.ac.at/forth/peep/sorted>
indicates that
only about 5% of the NEXTs come from LITs; so, if your enhanced NEXT
costs only one cycle more (and it's likely that it costs more), LIT
would have to cost >20 cycles to make that idea break even.
Something that is cheaper wrt run-time is to introduce
superinstructions for sequences of some primitive followed by a
literal: Then you compile the ordinary primitive in the normal case,
and the superinstruction, if there is a subsequent literal. At
run-time there is no need for a conditional branch in NEXT, and no
need for the ****ft.
And once you use superinstructions, there is no need to restrict
yourself to combinations where LIT is second. You can combine any
sequence that occurs frequently.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
|
