[SLOF] [PATCH] libc: The arguments of puts() can be marked as "const"

Alexey Kardashevskiy aik at ozlabs.ru
Thu Jul 13 23:04:22 AEST 2017


On 13/07/17 18:10, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Jul 13, 2017 at 12:42:32PM +1000, Alexey Kardashevskiy wrote:
>> On 12/07/17 22:41, Segher Boessenkool wrote:
>>> On Wed, Jul 12, 2017 at 06:53:38AM +0200, Thomas Huth wrote:
>>>> That's kind of ugly. Why not simply:
>>>>
>>>> diff --git a/slof/paflof.c b/slof/paflof.c
>>>> index 50b4adf..ea3c145 100644
>>>> --- a/slof/paflof.c
>>>> +++ b/slof/paflof.c
>>>> @@ -81,8 +81,8 @@ long engine(int mode, long param_1, long param_2)
>>>>                 LAST_ELEMENT(xt_FORTH_X2d_WORDLIST).a = xt_LASTWORD;
>>>>
>>>>                 // stack-pointers
>>>> -               dp = the_data_stack - 1;
>>>> -               rp = handler_stack - 1;
>>>> +               dp = the_data_stack;
>>>> +               rp = handler_stack;
>>>>
>>>>                 // return-address for "evaluate" personality
>>>>                 dummy.a = &&over;
>>>
>>> Paflof originally had options to cache 0, 1, or 2 top-of-stack elements.
>>> Now it is always 1; it is usually fastest (2 is theoretically a tiny
>>> bit better, but a bit worse in practice).
>>
>> Sorry I am missing the connection between this 1-cell-cache and the size of
>> the stack :)
> 
> I left out a bit, and I didn't check either (it actually caches 0 elements
> currently).  The # elts cached together with where the stack pointer
> points exactly (see below) matters for the code size and speed of the
> primitives.
> 
> The stack grows upward, and it's a full stack (i.e. the stack pointer
> points to the top used element), which means for an empty stack it
> points to one below the stack.
> 
> This means that for pushing to the stack we can use a store-with-update
> instruction (stdu).  This generates good code for most primitives,
> better than the other stack pointer offsets.


Aha! So this "stdu" actually explains the current behaviour. Thanks for the
explanation, I'll add it to the commit log for that type cast you suggested.


> 
> It doesn't matter all that much; most of the time you are just waiting
> for some i/o to happen.
> 
> 
> If you want to change it, you should look at DEPTH, PICK, ROLL, and
> the things that change stack and THROW/CATCH and such.  And anything
> else that "manually" accesses the stacks...
> 
> 
> Segher
> 


-- 
Alexey


More information about the SLOF mailing list