To: stik@ON-Luebeck.DE
Subject: Re: [10] STIK: STIK/DIALER                                                       


On Mon, 2 Sep 96 08:02:18 GM Guy Harrison <test@swampd wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-
>
----- snip ----- re: difficulty of having direct message responses
Yep, I agree.


----- snip ----- re: usefulness of constant message sizes
>
>I think a good compromise would be for the buffer code to test the 
>message length. 16 bytes uses 4 move.l (a0)+, bigger uses a general 
>block copying routine. Btw, my knowledge of assembler cycles is non 
>existent - is that the fastest way or would movem.l be better?

The main overhead lies in an extra opcode modifier word, so with exactly 4
longs to move, it is doubtful whether anything can be gained, since the two
'movem.l' codes needed will use the same 4 words needed by the four
'move.l (a0)+,(a1)+' that I would use. I'm not sure if there is any overhead
difference in the address decoding here, but I don't really think so.

There is however the difference of register usage, which is why I would opt
for the four move solution rather than the double movem in this case.


----- snip ----- re: fetching short messages in full with 'is_msg'
>
>You've convinced me.

Good, I think we are closing in on a final form for this idea.


----- snip ----- re: simulated TOS/TTP app ids (negative ids agreed)


>>Ok, that is clear, and I do agree.  Prioritizing is very important,
>>and the lack of such is a problem in the AES message implementation.
>>
>>BTW, if the 'Heart of Gold' had had prioritization, Arthur's famous
>>'Tea question' would not have had half as exciting consequences.
>
>I've been racking my brains over that. I can remember the probability 
>factor dropping but not what happened over the tea! Looks like I'll 
>have to dig out the cassette! :-))

Yep, or the book.  If you just want to find something that's usually faster.
Come to think of it, there's some things added into the books that were
not in the original broadcasts, and some that were subtly altered.
I'm not sure if the 'Tea question' is one of those or not.


----- snip ----- re: not adding unnecessary stuff (agreed)


>>My only worry is that trying to keep things 'too' general may prevent
>>optimizations that could make a major difference in terms of speed.
>
>If we modify the spec slightly to include the automatic 16 byte 
>transfer you suggest and only resort to a block copy for longer 
>lengths then I think we have solved it.

Yes, I agree.


>Now for the buffer format ... I'll have to leave this to another 
>email, I'm very tired atm. Anything I think of now will definately be 
>the worst possible thing that could be invented! :-)

Ok, well take that next time then.

In case you haven't noticed yet, we've now reached full agreement on all
points brought up so far, so we'll have to invent something to argue over.
:-)

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
