[SLOF] [PATCH 4/4] fbuffer: Implement RFILL as an accelerated primitive

Thomas Huth thuth at redhat.com
Mon Aug 3 16:36:14 AEST 2015


On 02/08/15 12:07, Segher Boessenkool wrote:
> On Sun, Aug 02, 2015 at 09:52:38AM +0200, Thomas Huth wrote:
>>> "register" is useless.
>>
>> ... apart from the fact that you can not take the address of a register
>> variable with the "&" operator and thus gain a little bit more hope that
>> the compiler puts the variable into a register.
> 
> Not really no.  Not at all, in fact.
> 
>> Apart from that, I know, the compiler can ignore this completely ... but
>> it gives me a better feeling when I write it there ;-)
> 
> Better start using "auto" as well then :-)

Well, according to http://www.seebs.net/faqs/c-iaq.html#question-1.8
I should not use this variable type for frame buffer code ;-)
(unless we add a nice car as splash screen logo in SLOF)

> This whole RFILL, RMOVE business is iffy: for "real" I/O accesses (not just
> uncached memory as you use it for) you really need to enforce the access
> size, not for speed but for correctness.

True - but it is currently only used for frame buffer accesses and it
seems to work fine there with all graphic cards that we've used in the
past ... and to enforce the access size we would need another Forth word
anyway which takes an additional size parameter. So if we ever need it,
let's rather introduce a new Forth word instead.

 Thomas



More information about the SLOF mailing list