Integrated TFT controller in PIC MCUs

glen herrmannsfeldt schreef op 10-Jan-15 om 3:25 AM:
> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>> On 2015-01-09, Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
>>> Well I really cannot simplify the concept of saving say 4 out of 32
>>> registers, using only them in an IRQ handler, then restoring only
>>> them and returning from the exception.
>
>> In the general case, you have to push and pop all the registers every
>> time you take an interrupt.
>
> Some processors have multiple register sets that might avoid that.
> SPARC has register windows, such that they don't have to save to
> memory until all the windows are in use.  I don't know if that is
> for interrupts, too.

That is a nice concept, but it has two problems:

- when you overflow the avaiable resister sets, you must spill to 
memory. whether you need to do this, depends on where you are in the 
register set. this makes timing difficult to predict, which is not nice 
for a real-time system

- imagine a context switch. now you have to save/restore all register sets!

In general, fat-context CPUs are better at single-threaded no-interrupt 
applications, but worse for switch-often interrupt-heavy applications.

Wouter van Ooijen

Anders.Montonen@kapsi.spam.stop.fi.invalid schreef op 10-Jan-15 om 10:51 AM:
> Vladimir Ivanov <none@none.tld> wrote:
>
>> Do all instruction forms have wider version to accomodate R8-R15 usage?
>
> I believe that is the case.

Not in Cortex-M0. About the only thing you can do with the upper 
registers (r8-12) is copy to/from a lower register. As an illustration: 
a cooperative context switch on a cortex-m0:


    .cpu cortex-m0
    .global switch_from_to
    .text
    .align 2

    // extern "C" void switch_from_to(
    //    int ** current_stack_pointer,
    //    int * next_stack_pointer
    // );
switch_from_to:

    // save current context on the stack
    push { r4 - r7, lr }
    mov r2, r8
    mov r3, r9
    mov r4, r10
    mov r5, r11
    mov r6, r12
    push { r2 - r6 }

    // *current_stack_pointer = sp
    mov r2, sp
    str r2, [ r0 ]

    // sp = next_stack_pointer
    mov sp, r1

    // restore the new context from the new stack
    pop { r2 - r6 }
    mov r12, r6
    mov r11, r5
    mov r10, r4
    mov r9, r3
    mov r8, r2
    pop { r4 - r7, pc }

Wouter van Ooijen

Wouter van Ooijen <wouter@voti.nl> wrote:
> Anders.Montonen@kapsi.spam.stop.fi.invalid schreef op 10-Jan-15 om 10:51 AM:
>> Vladimir Ivanov <none@none.tld> wrote:
>>
>>> Do all instruction forms have wider version to accomodate R8-R15 usage?
>> I believe that is the case.
> Not in Cortex-M0.

That is true, but they implement ARMv6-M Thumb, not Thumb-2.

-a

Anders.Montonen@kapsi.spam.stop.fi.invalid schreef op 10-Jan-15 om 11:45 AM:
> Wouter van Ooijen <wouter@voti.nl> wrote:
>> Anders.Montonen@kapsi.spam.stop.fi.invalid schreef op 10-Jan-15 om 10:51 AM:
>>> Vladimir Ivanov <none@none.tld> wrote:
>>>
>>>> Do all instruction forms have wider version to accomodate R8-R15 usage?
>>> I believe that is the case.
>> Not in Cortex-M0.
>
> That is true, but they implement ARMv6-M Thumb, not Thumb-2.

In that case I was confused about the context of the statement :)

Wouter

On 09/01/15 23:04, Dimiter_Popoff wrote:
> On 09.1.2015 г. 11:47, David Brown wrote:
>> On 09/01/15 00:22, Dimiter_Popoff wrote:
>>> On 09.1.2015 г. 00:53, Wouter van Ooijen wrote:
>>>> Dimiter_Popoff schreef op 08-Jan-15 om 11:18 PM:
>>>>> On 08.1.2015 г. 23:25, David Brown wrote:
>>>>>> ...  (Just as "cpus should
>>>>>> have more than 16 core registers" is a good reason for disliking
>>>>>> ARM's,
>>>>>> if that is your opinion.)
>>>>>
>>>>> Results of arithmetic calculations are not exactly what I would
>>>>> call an
>>>>> opinion.
>>>>> 16 registers - one of which being reserved for the PC - are too few
>>>>> for
>>>>> a load/store machine.
>>>>
>>>> 16 is a fact, but the rest is nothing but opinion.
>>>>
>>>>   > Clearly it will work but under equal conditions
>>>>> will be slower than if it had 32 registers, sometimes much slower.
>>>>
>>>> More registers can be slower too.
>>>
>>> Yes, 32 is about the optimum I suppose. But I have not really analyzed
>>> that, what I have - and demonstrated by an example which you chose to
>>> ignore - is the comparison 32 vs. 16.
>>
>> Certainly it is possible to pick examples where 32 registers is more
>> effective than 16 - but equally we can pick examples where 16 registers
>> is more efficient (such as context switching, or code with a lot of
>> small functions).  Examples are illustrative, but not proof of a general
>> rule.
>
> You have yet to prove this point. Context switching is not a valid
> example, as I explained in my former post which you must have read
> prior to replying to (for those who have not, context switching is
> responsible for a fraction of a percent of CPU time, consequently
> halving or even completely eliminating that can bring a fraction of
> a percent improvement, i.e. it is negligible).

I think it would be wrong to talk about /proving/ points here - proper 
proof would require implementing the same algorithms in different 
architectures (or preferably in the same basic architecture, but with 
different register counts) and comparing code densities, run times, 
cache hit/miss counts, memory bandwidth, etc.  That is clearly far 
beyond what anyone will do for a Usegroup post!

Context switching is not a valid example for /you/, based on the figures 
/you/ gave.  But it is certainly not something that can be dismissed so 
easily.  I have written systems that had timer interrupts at 100,000 
times per second - thus interrupt overhead is 100 times as important as 
in your single example with 1000 interrupts per second.  I have written 
one system where there were 40 clock between interrupts - that does not 
leave a lot of time for context saving and restoring.

In general, in bigger systems (and PowerPC cores tend to be used in 
bigger systems than most of the embedded cores we see here) you try to 
avoid many interrupts, and prefer DMA and more sophisticated peripherals 
to keep the interrupt rate low.  In smaller microcontrollers, you don't 
have such sophistication - your UART might have only a single buffer, so 
you will have interrupts for every character transmitted or received. 
But interrupts are less of an overhead, partly because of the lower 
register count.  It's a different balance.

Other than interrupt context switches, there is also function call 
overhead.  I don't know what sort of calling conventions you use in your 
VPA, but for high-level languages there is normally a defined convention 
with some registers being caller-saved (or "volatile") and others being 
callee-saved (or "non-volatile").  The split can vary between compilers 
on a target, or can been defined by the target's standard ABI.  When you 
are calling unknown code (i.e., code from a separately compiled module), 
the compiler (or assembly programmer) must follow the calling 
convention.  That means a function must save any callee-saved registers 
before using them, in case the calling function had data there.  And it 
must save caller-saved registers before function calls, in case the 
called function uses them.  There is always a significant amount of 
unnecessary saving and restoring in this process, and it increases with 
the number of registers in the system and with the number of small and 
simple functions (because with larger functions that really use the 
data, the save/restores are no longer unnecessary and therefore not 
overhead).

So if a PPC function (following the standard PPC EABI conventions) needs 
to use any of the 18 "non-volatile" registers, it must save the old 
values and restore them on exit - even if the calling function does not 
need the old values.  And if it is calling another function, then it 
must save any of the 11 "volatile" registers it wants to keep - even if 
the called function does not touch them.

>
> I would certainly be interested in the example you claim to be able
> to produce demonstrating how 16 registers can be more effective.
> My example covers a typical, widespread application - that of a FIR.
> Let us see yours.

I can't produce a /function/ that is more efficient with 16 registers 
than 32 registers - but I hope that above I have explained how it make a 
difference with chains of small functions (or functions with few 
register demands).


I think it is reasonable to say that as programs (in the embedded world) 
have got bigger, memories have got bigger, and compilers have got 
better, then the balance for many systems has moved more towards 32 
registers rather than 16 registers, in the same way that it has moved 
towards 32-bit cpus from 8 and 16-bit cpus.

>
>>>> More registers => more bits in an instruction to specify a register =>
>>>> more to read from code mempry => slower
>>>
>>> Not really. Load/store machines typically  have a fixed 32 bit
>>> instruction word; using that for only 16 registers is simply
>>> waste of space, you will have less information packed in the
>>> opcode thus you will need more opcodes to do the same job, thus
>>> having to do *more* memory fetches.
>>
>> Many load/store machines have some sort of compressed or limited
>> instruction format for greater efficiency (especially of instruction
>> cache).  ARM has a couple of "thumb" modes, MIPs have an equivalent, and
>> on the PPC I have seen various schemes.
>
> I'd be interested to see those sub-32 bit opcode schemes you talk about
> on power, I have yet to encounter one of them. Certainly none of them
> is present on the cores I use or have investigated. (I am just curious,
> not in need of something like that).

The one I am most familiar with is VLE, which is used by many of 
Freescale's PPC microcontrollers.  (It may be used by others too, but I 
have only used PPC from Freescale.)  I also remember that Freescale had 
some chips with a sort of compression scheme where code was decompressed 
while it was loaded into cache - but I have forgotten the details.  VLE 
is the same basic idea as ARM's Thumb2 and the MIPS equivalent.

>
>> Even in the full 32-bit ARM set, the bits "saved" by having fewer
>> registers are used for the conditional execution bits and the barrel
>> shifter.
>
> Can you please elaborate on that. What can ARM do using the barrel
> shifter which you cannot do using the likes of rlwinm, rlwnm or rlwimi
> on power?

The barrel shifter bits apply to a wide range of ARM instructions - 
meaning you can effectively tag a zero-cost shift instruction into many 
other instructions.  Thus if you want "a = b + c * 16;", on the PPC you 
need two instructions (shift then add) with pipeline/scheduling 
considerations between them, while on the ARM it is done in one 
instruction and one cycle.

With 16-bit Thumb instructions, the barrel shifter only works on loads, 
stores, and specific rotate/shift instructions - with 32-bit Thumb and 
full ARM instructions it works on a wide range of instructions.

>
>> Every bit of space in the instruction set is important.  Using them to
>> support extra registers may be the best overall tradeoff in some cases,
>> but it is always a tradeoff.
>
> This kind of general talk leads nowhere here as you may have found out
> in previous discussions. If you cannot support a claim by a valid
> particular example you are saying nothing.
>
> I explained that 16 registers are too few for a load/store machine,
> gave an example to make it easier to understand why (to be able to
> compensate for the pipeline delay).
>
> You are just repeating your opinion basing it on nothing.

And you in turn are generalising based on an example and your own very 
specialised experience.  I hope that what I wrote earlier makes it clear 
why I think 16 registers can be an advantage, and why I think your 
example cannot count as a general proof or argument (though I happily 
accept it as an example of when 32 registers is very useful).

Beyond that, I would say that even if 16 registers is not /more/ 
efficient than 32 registers, I have yet to see any reasoning for why 32 
registers is /significantly/ more useful for the type of code generally 
seen in microcontrollers (and yes, I have no choice here but to talk of 
generalities).  A filter algorithm might run faster with more registers 
- but it would do even better by using additional DSP-specific support 
(such as the DSP registers and instructions on the Cortex M4 compared to 
the M3) or SIMD support (Alitvec on PPC, Neon on ARM).

I will try not to repeat myself, but I hope you can see that this is 
necessarily a generalised discussion, based strongly on opinion and 
personal experience - unless you want to give several whole programs 
implemented on at least two architectures using commonly used tools and 
techniques (i.e., C code rather than VLA code) as real evidence.

>
>>> If you become familiar with the power architecture instruction set
>>> you will find very little room for performance improvement, the
>>> person who did it knew what he was doing really well.
>>>
>>
>> It's a nice architecture (apart from the backwards bit numbering!).
>
> The bit numbering is simply big endian. I also
> have had my trouble with it of course but it is easy to get used to.

Yes, it is fine when you are used to it - but very weird to start with, 
and different from everything else (including the numbering used on 
other big-endian processors I have used, such as M68K/ColdFire).  You 
have to double-check everything when you are connecting address line A31 
on the MPC to A0 on the external RAM chip!  And then Freescale's 
documentation freely mixes up 64-bit PPC conventions with the 32-bit 
conventions, so you find you are trying to set "bit 59" of a register by 
writing the value 16...  It was even more "fun" when I found Freescale 
had also mixed it up in a couple of register definitions in a header file.

> In VPA I do use both - crazy as it may seem once you get used to
> think on it it is no longer an issue.
> But overall having big endian bit numbering on a big endian machine
> is the correct thing to do. If one chooses to use a power core in
> little endian mode much of the time one will be somewhat screwed
> I suppose.

To me, "bit 0" is always the least significant bit regardless of the 
endianness of the chip.  But I try not to start wars over it :-)

>
>> ... But
>> it is a very complex architecture - for smaller devices (say 200 MHz,
>> single core - microcontroller class cpus) a PPC core will be much
>> bigger, more difficult to design and work with, and take more power than
>> an ARM (or MIPS) core.
>
> Oh I agree power does not make sense on the smallest of MCUs, of course.
> In fact I don't think it makes much sense below a megabyte of RAM
> or so (but then that's me and is based on my needs so far, I am not
> claiming this to be some general rule).

Fair enough.

>
>>> Not at all. You can always save/restore even just 1 register if you
>>> want to on a 32 register machine, what you *cannot* do on ARM is
>>> have more than 13 registers to use in an IRQ handler when you need
>>> them - so you will need *more* memory accesses in this case.
>>
>> That makes no sense to me.
>
> Well I really cannot simplify the concept of saving say 4 out of 32
> registers, using only them in an IRQ handler, then restoring only
> them and returning from the exception.

When your interrupt function is a leaf function, it's no problem to only 
save the registers you need (regardless of the size of the register set).

But when it is not a leaf function, and you are calling other functions 
(whose code you do not know), you have to follow the calling conventions 
and assume that the called function will destroy all "volatile" 
registers - that's at least 11 extra register saves in a PPC EABI 
system, as well as the link register, CCR, etc.

>
>>> And since the latency which matters is the IRQ latency (tasks get
>>> switched once in milliseconds, IRQ latencies may well have to be
>>> in the few uS range) - the time on save/restore all registers
>>> is negligible (e.g. 32 2.5nS cycles once per mS on a 400 MHz power
>>> core, or 0.008% of the time).
>>>
>>
>> The time needed to save and restore all registers may not be relevant in
>> a given application, but it is not irrelevant or negligible in all cases.
>>
>
> So show us one such case.

On one PPC system I worked with which did not support individual 
interrupt vectors, /all/ registers were saved (and later restored) 
because the vector code was calling unknown external code.  32 x 32-bit 
general purpose registers plus 32 x 64-bit floating point registers, 
stored on external SRAM with 2 cycle accesses meant 400 cycles just for 
the register save and restore - not including the memory bandwidth for 
reading the code or any other processing time.  Even if I had spend time 
optimising it by limiting the storage to the volatile registers (since I 
knew the interrupt functions all followed the EABI conventions 
correctly), and therefore halved the overhead, it would still have been 
very large.

>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff, TGI             http://www.tgi-sci.com
> ------------------------------------------------------
> http://www.flickr.com/photos/didi_tgi/
>
>
>

On 09/01/15 16:30, Vladimir Ivanov wrote:
>
> On Fri, 9 Jan 2015, David Brown wrote:
>
>> On 09/01/15 10:54, Vladimir Ivanov wrote:
>>>
>>> On Fri, 9 Jan 2015, David Brown wrote:
>>>
>>>> For microcontrollers, such as the Cortex M devices, I think 16
>>>> registers
>>>> is a good balance for a lot of typical code.
>>>
>>> In Thumb2 you work directly with 8 GP registers, indirectly with few
>>> like PC and SP, and accessing the rest of the GPRs is different and/or
>>> has penalties.
>>
>> As far as I understand it, accessing the other registers means 32-bit
>> instructions rather than the short 16-bit instructions.  So accessing
>> them has penalties compared to accessing the faster registers, but not
>> compared to normal ARM 32-bit instructions.
>
> Yes, longer code sequences, and most likely very limited instruction
> forms. The latter leads to shuffling of data between the regular 8 GPRs
> and the other, "unregular" GPRs.
>

That was needed for Thumb, but not for Thumb2 - you simply use the 
32-bit instructions and have access to the same registers as you would 
with 32-bit ARM codes.  If you like, you can think of Thumb2 as being 
mostly the same as 32-bit ARM (losing a little barrel shifter and 
conditional execution capability) with the addition of 16-bit 
"short-cuts" for the most commonly used instructions.

>>> Just trying to say that it is a moot point. And personally, I never
>>> understood the existence of Cortex-M - why cripple the ability to switch
>>> to native 32-bit mode, if most or all of the underlying logic is there?
>>
>> My knowledge of the details is weak, but AFAIK the only thing you really
>> lose with Thumb2 compared to ARM instruction sets is the conditional
>> execution flags - with ARM, you can use the flags with most
>> instructions, while with Thumb2 you have the if-then-else construction.
>> (You also lose the barrel shifter on some instructions, but that is not
>> going to affect much code.)
>
> I am not Thumb2 expert, either. As a very strong personal (biased)
> opinion, I don't find it elegant at all. MIPS16e impressed me bit more
> with their EXTEND instruction.

I haven't studied either Thumb2 or MIPS16e (or PPC VLE) in detail, but 
they all seem to be a similar solution to a similar problem - making a 
variable-length encoding scheme that is easy to decode, keeps common 
instructions short, but makes it easy to access the full range of the 
cpu's abilities.

>
> What I am trying to communicate, is that the CPU core with all the
> blocks is there. Thumb2 is more or less a decoder, just like the ARM
> mode is. Same with MIPS32 and MIPS16e. Why would one cripple something
> by removing one of the decoders? The power savings are negligible.
>
> ARM7TDMI was more balanced in that regard.

No, the original Thumb instruction set only gave access to some of the 
cpu and let you write significantly slower but more compact code than 
full ARM.  That's why they had to keep the ARM decoder too - if you 
needed fast code, you had to use the full instruction set.  And no one 
considered the mix of two instruction sets to be "balance" - polite 
people called it a pain in the neck.

Thumb2 lets you write code that is about 60% of the size of ARM code, 
and is often /faster/ than 32-bit ARM code, since you can get almost all 
of the functionality while being more efficient on your memory bandwidth 
and caches.

>
>> With the original Thumb, ARM kept the normal 32-bit ARM ISA as well
>> because for some types of code it could be significantly faster.  But
>> with Thumb2, there is almost no code for which the full 32-bit ARM
>> instructions would beat the Thumb2, taking into account the memory
>> bandwidth benefits of Thumb2.
>
> Any pointers to data showing this? Never heard of it so far, and does
> not reflect my experience.
>
> Why'd they include ARM mode at all in the Cortex-A series? :-)

For backwards compatibility.  In Cortex M applications, code is 
generally compiled specifically for the target - so there is no need for 
binary compatibility.  But for Cortex A systems, you regularly have 
pre-compiled code from many sources, and binary compatibility with older 
devices is essential.

On 10.1.2015 г. 20:07, David Brown wrote:
> On 09/01/15 23:04, Dimiter_Popoff wrote:
>> On 09.1.2015 г. 11:47, David Brown wrote:
>>> On 09/01/15 00:22, Dimiter_Popoff wrote:
>>>> On 09.1.2015 г. 00:53, Wouter van Ooijen wrote:
>>>>> Dimiter_Popoff schreef op 08-Jan-15 om 11:18 PM:
>>>>>> On 08.1.2015 г. 23:25, David Brown wrote:
>>>>>>> ...  (Just as "cpus should
>>>>>>> have more than 16 core registers" is a good reason for disliking
>>>>>>> ARM's,
>>>>>>> if that is your opinion.)
>>>>>>
>>>>>> Results of arithmetic calculations are not exactly what I would
>>>>>> call an
>>>>>> opinion.
>>>>>> 16 registers - one of which being reserved for the PC - are too few
>>>>>> for
>>>>>> a load/store machine.
>>>>>
>>>>> 16 is a fact, but the rest is nothing but opinion.
>>>>>
>>>>>   > Clearly it will work but under equal conditions
>>>>>> will be slower than if it had 32 registers, sometimes much slower.
>>>>>
>>>>> More registers can be slower too.
>>>>
>>>> Yes, 32 is about the optimum I suppose. But I have not really analyzed
>>>> that, what I have - and demonstrated by an example which you chose to
>>>> ignore - is the comparison 32 vs. 16.
>>>
>>> Certainly it is possible to pick examples where 32 registers is more
>>> effective than 16 - but equally we can pick examples where 16 registers
>>> is more efficient (such as context switching, or code with a lot of
>>> small functions).  Examples are illustrative, but not proof of a general
>>> rule.
>>
>> You have yet to prove this point. Context switching is not a valid
>> example, as I explained in my former post which you must have read
>> prior to replying to (for those who have not, context switching is
>> responsible for a fraction of a percent of CPU time, consequently
>> halving or even completely eliminating that can bring a fraction of
>> a percent improvement, i.e. it is negligible).
>
> I think it would be wrong to talk about /proving/ points here
 > ...

OK, I really meant "make" your point. Though in technical terms making
a point which cannot be proven is fairly pointless...

> Context switching is not a valid example for /you/, based on the figures
> /you/ gave.

So you understand that these figures are correct - but imply that
the example applies just to me. I thought we could agree at least
on the meaning of numbers.

>I have written systems that had timer interrupts at 100,000
> times per second

Which has *nothing* to do with context switching, if you do that and
save all registers instead of the minimum you have to you just don't
know what you are doing.

I know from threads from years past that you tend to mix up
task scheduling and interrupt processing but please understand
that there is a world of a difference between interrupt processing
and a task switch initiated by an interrupt.

You have not made a point - context switching is *not* a case
where 32 registers can be worse off than 16 in a non-negligible way
(negligible meaning performance cost within say 0.1%, latency-wise
same as 16 or better).

You have yet to give a valid example for what you claim.

> In general, in bigger systems (and PowerPC cores tend to be used in
> bigger systems than most of the embedded cores we see here) you try to
> avoid many interrupts, and prefer DMA and more sophisticated peripherals
> to keep the interrupt rate low.

This is wrong, it is not true that on larger systems interrupts must
be avoided.

You should understand that there is no such animal as "in general" in
engineering. Things we make have to *work*, so we have to go down to
the details.

  For example, on an mpc5200b based system, the one for
my everyday use for programming, emailing etc., running DPS of course,
I have plenty of interrupts all the time - from the display controller
vertical retrace, from the two PS2 ports where the mouse and the
keyboard are connected - each PS2 clock causes and interrupt and
yes, they can come at a faster rate than every 10uS - then there
are the ATA interface interrupts etc. etc.
These have *nothing* to do with task switching, neither do they
initiate one. Say the decrementer interrupt might initiate one and then
of course all regisrters will be shuffled - but *AFTER* the interrupt
has been served and unmasked again so that the interrupt latency
stays low (so a 10uS IRQ rate cannot not impress the machine).

Whatever example you try to come up with you will never find one
which requires saving *all* of the registers with the interrupts
masked - which means there is no performance advantage in having
16 rather than 32 registers, while the opposite is true most if
not all of the time.

> Other than interrupt context switches, there is also function call
> overhead.

Same concept, save/restore only what needs to be saved/restored.
Fewer registers will be as good only as long as you do not need
more registers, then you have to save/restore more *because*
you have fewer registers.
I explained that once already and I am doing it again for you,
please do not make me do it for a third time. Just think and be
willing to understand the obvious.

> I don't know what sort of calling conventions you use in your
> VPA, but for high-level languages there is normally a defined convention
> with some registers being caller-saved (or "volatile") and others being
> callee-saved (or "non-volatile").  The split can vary between compilers
 > ...

This is irrelevant, we are comparing cores. Whether this or that
compiler got some of it basics right or wrong has nothing to do with it.
The fundamental principle - "save/restore only what you have to"
applies in all cases of programming.

IOW if you waste resources by saving/restoring more than you have to
you are doing only a little better than masking all interrupts and
jumping into a " bra *" loop; the ways to destroy something working
are probably infinite, these are only two of them.

>> I would certainly be interested in the example you claim to be able
>> to produce demonstrating how 16 registers can be more effective.
>> My example covers a typical, widespread application - that of a FIR.
>> Let us see yours.
>
> I can't produce a /function/ that is more efficient with 16 registers
> than 32 registers - but I hope that above I have explained how it make a
> difference with chains of small functions (or functions with few
> register demands).

I know you cannot produce an example - the above (much of it clipped)
was irrelevant.

> I think it is reasonable to say that as programs (in the embedded world)
> have got bigger, memories have got bigger, and compilers have got
> better, then the balance for many systems has moved more towards 32
> registers rather than 16 registers, in the same way that it has moved
> towards 32-bit cpus from 8 and 16-bit cpus.

You still do not get it, do you.

32 registers are not just *better*, they are a necessity on a load/store
machine with a pipeline (deep something like 5-6 stages). You just
cannot keep the pipeline full if you have only 16 registers without
stalls because of data dependencies.

> Beyond that, I would say that even if 16 registers is not /more/
> efficient than 32 registers, I have yet to see any reasoning for why 32
> registers is /significantly/ more useful for the type of code generally
> seen in microcontrollers (and yes, I have no choice here but to talk of
> generalities).

My FIR example demonstrated what is about a 3-fold improvement, and
above I just explained - *again* - why. It should be easy to see how
this applies by far not just to FIR but to any computationally
intensive algorithm where data dependencies would kick in.

>  A filter algorithm might run faster with more registers
> - but it would do even better by using additional DSP-specific support

Obviously hardware other than a general purpose core can be built
to do things the core cannot do.

We are comparing the cores here.

> On one PPC system I worked with which did not support individual
> interrupt vectors, /all/ registers were saved (and later restored)
> because the vector code was calling unknown external code.

Poor programming. IRQ routines may never call unknown external
code.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Wouter van Ooijen <wouter@voti.nl> wrote:

(snip)
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>> On 2015-01-09, Dimiter_Popoff <dp@tgi-sci.com> wrote:
(snip)
>>> In the general case, you have to push and pop all the registers every
>>> time you take an interrupt.

(snip,then I wrote)
>> Some processors have multiple register sets that might avoid that.
>> SPARC has register windows, such that they don't have to save to
>> memory until all the windows are in use.  I don't know if that is
>> for interrupts, too.
 
> That is a nice concept, but it has two problems:
 
> - when you overflow the avaiable resister sets, you must spill to 
> memory. whether you need to do this, depends on where you are in the 
> register set. this makes timing difficult to predict, which is not nice 
> for a real-time system

Seems that they thought of that.
 
> - imagine a context switch. now you have to save/restore all 
> register sets!

and that.
 
> In general, fat-context CPUs are better at single-threaded no-interrupt 
> applications, but worse for switch-often interrupt-heavy applications.

http://www.gaisler.com/doc/sparcv8.pdf

Section D.8 explains that one. For the more usual case where function
calls are much more common than context switch, and you want to minimize
total overhead, more register windows are better. 

For SPARC, there is a register mask that controls how many are used
by user mode code. Changing that allows supervisor code to use some,
such that one can optimize overall between user and supervisor code.

And finally, they consider the case where context switch time is
most important. In that case, they allocate register windows between
tasks, such that one can do task switch by only changing the register
mask and current window, and not storing any to memory.  
The OS has complete control over how the windows are used.

-- glen
 

On 2015-01-10, Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
> I am still somewhat amazed at what was said.

That just shows the disconnect between what you do and what the rest
of the world does. :-)

> What on earth is there to stop people from doing something
> *that* simple - here are two IRQ handlers on a small MCU, I used
> an mcf52211 a couple of months back to make a HV source - it
> does the PWM/regulating, overcurrent protection/limiting, serial
> communication etc., all in all 4 tasks, several IRQs. Took me
> about 2 weeks to program (I had hoped it would take 2 days but
> I had completely forgotten the insides of the 52211 so I had to
> recall a lot which is where the 2 weeks went). A total of about
> 250k sources, the object code being almost 9 kilobytes.
>
> So here are two IRQ handlers where hopefully it is obvious how
> only what is needed is saved and restored, pretty basic stuff:
>
> http://tgi-sci.com/misc/hvst0q.gif
>
> This is not VPA, just plain 68k (well, CF) assembly, so it is
> far from being taken from my own world.
>

While the actual wrapper around the device specific interrupt handler
(ie: the generic IRQ code which runs before you get to the device
specific handler itself) is generally still assembly language, most
people don't write the actual device specific handler in assembly
language any more, but use a higher level language such as C instead.

Once you do that, the IRQ wrapper needs to save all the registers the
C compiler could potentially use, including all the temporary registers,
before the wrapper calls the device specific handler.

> I just wonder how hopeless things must have become to question
> the viability of doing something that basic.
>

Different set of tradeoffs. The higher level language code can
potentially be reused on multiple architectures (or if that's not
possible in a specific case, can at least used as the starting point
for another driver); your PowerPC specific assembly language code cannot
be reused in such a way.

What works for you in your restricted environment doesn't work when
you need your code to work in a generic environment across a wide range
of architectures.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2015-01-09, Anders.Montonen@kapsi.spam.stop.fi.invalid <Anders.Montonen@kapsi.spam.stop.fi.invalid> wrote:
>
> microMIPS has instructions for pushing and popping the callee-save 
> registers onto the stack (LWM32/LWM16/SWM32/SWM16). This is notable in a 
> way because MIPS have traditionally avoided committing an ABI into the 
> architecture.
>

I didn't know that. Thanks.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world