Re: [Silgraphite-devel] New engine feature proposal

[Martin H. <mar...@si...>]

Dear Sharon,

> So you're saying that we would create 16 built-in slot attributes 
> called ref1, ref2, ref3, whose values are expected to be a slot 
> reference. (I assume these could be #defined to have more meaningful 
> names just like user1, user2, etc.)
> 
> This seems fairly easy at the compiler level. I must be missing 
> something. :-)

:) Yes it's that simple, at the syntax level.

> Do the values need to be computed (eg, @user1+someglyphattr), or will 
> they always be simple integers (@1, @2, etc)?

No the values don't need to be computed, but notice that we need a special opcode to get from a slot-ref to a slot pointer in the engine.

> > Anyway my proposal is to add a slot attribute class .ref as in:
> >
> > cBase cAttach { ref1=@1 };
> >
> > I think I won't need more than 16 of these.
> >
> > In opcode terms we are thinking the best thing is to have a separate stack onto which pointers to slot are put.
> 
> Is this what you are calling the "slot stack"?

Yes.

> > PushSlot slot_ref : finds the point to the given slot and push it onto the slot stack
> 
> I assume you mean the pointer...

typo: finds the pointer to the given slot. So yes.

> 
> > SetISlotRefAttr slot_ref index : pops the slot stack and stores in the given slots given slot reference attribute
> > GetISlotRefAttr slot_ref index : gets the slot reference attribute from the referenced slot and pushes it onto the slot stack.
> >
> > The immediate thought is that all opcodes involving a slot_ref are now going to need slot stack based versions. But an alternative is to say that a slot_ref = 0x7F would mark that the slot_ref is to come from the slot stack rather than as an index into the slot array. This works because rules can't be longer than 64 slots long anyway so you shouldn't be up that high.
> 
> I don't understand this. Are you saying that AttrSetSlot and 
> IAttrSetSlot need to be able to pop from the new slot stack as well as 
> the standard stack (in order to set slot-ref slot attributes on the 
> current slot)? But if so, how does the 0x7F play in, where does it go? 
> Or does this refer to PushAttToGlyphAttr and PushAttToGlyphMetric? 
> (but I'm not clear why that would be needed).

Sorry, yes it's PushISlotAttr, PushGlyphAttr, PushGlyphMetric. I.e. wherever a slot-offset is used (which is always a parameter and never on the stack), you can use a slot-offset of 0x7F and the opcode will use the current top of slot stack as the slot to use instead of that referenced by the slot-offset.

> Isn't the whole purpose of a stack to handle arbitrarily 
> complex/nested arithmetic operations? So if there is no arithmetic 
> being done on a slot-reference value, why have a stack at all? Why not 
> just 16 "registers"? Is that what you're suggesting? Or is arithmetic 
> in fact needed to calculate the index of the slot?

The reason for a separate stack is so that you can copy values from one slot to another explicitly. Thus to do the type of referencing I think I'm going to need I will do something mad like:

c_base c_base{ref1 = @1; ref2=@1.ref1; ref3=@1.ref2; ref4=@1.ref3; ...} / _ [long context] _;

This is the only real use case I can see for having a slot stack. If you can find a natural, safe, low cost way of achieving the same thing. I'm very open to an alternative implementation approach.

> (And what is a non-popping stack, anyway? Aren't pushing and popping 
> inherent in the definition of a stack? :-) )

If you define a stack that way, then it isn't a stack. But I bet if I said it was a log you wouldn't immediately have understood what I was talking about ;)

GB,
Martin