Deprecate .HLL_map

[kjstol]

On Sat, Jan 24, 2009 at 8:10 PM, Andrew Whitworth <wknight8111 at gmail.com>wrote:

> Following my investigations into TT#216, and some discussions I've had
> with NotFound, I suggest we deprecate the .HLL_map directive. Some
> points:
>
> 1) .HLL_map fails for classes generated at runtime. See
> compilers/imcc/imcc.y:953 for the current behavior of it. IMCC looks
> up the type number at compile time, but the class doesn't exist yet
> until runtime. It works fine for PMC types that are known at compile
> time, but it doesn't work and is not easily extendible for classes
> created at runtime. Fixing it so that it does work for runtime classes
> would require some significant changes under the hood and could lead
> to an across-the-board performance reduction (at least using the few
> methods I've brainstormed so far).


Maybe, for sake of documentation of design decisions, it'd be good if you
could elaborate on the methods.
(or put it in the book)

>
> 2) The Interpreter PMC has a method "hll_map" that can be used to
> accomplish the same thing at runtime. This works for C-based PMCs and
> PIR-based classes equally and transparently (to the end user).


A simple principle: Everything that can be done during compile-time is a win
over doing it during run-time.
(however, that is not to say that I have a particular opinion on whether to
keep it, just saying..)

>
> 3) There is a little bit of additional overhead, calling the getinterp
> opcode and then calling the method on the opcode. However, I suspect
> that most programs will use a very limited number of these operations
> so it shouldn't be too much of a performance penalty.


See my remark in 2). I guess it's a question of how much is the total
performance overhead; if it doesn't happen too often, then this is not a
problem. It's also nice if there's one canonical way of doing the mapping,
which means less code, which means less maintenance.

>
> 4) If we were interested in increasing the speed of the operation
> anyway, we could create an hllmap opcode to handle it. I don't think
> this is necessary now, but it's an interesting optimization
> possibility for later.
>
> I'd like to add .HLL_map to the list of deprecated things, probably
> for the 0.9.1 release if possible. Comments?
>
> --Andrew Whitworth



kjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.parrot.org/pipermail/parrot-dev/attachments/20090125/986d32a6/attachment.htm