On Feb 4, 7:03=A0pm, Robert Adsett <s...@aeolusdevelopment.com> wrote:
> On Feb 3, 5:33=A0pm, Didi <d...@tgi-sci.com> wrote:
>
> > On Feb 3, 9:56=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> > > Didi wrote:
> > > > In the context of a single bus master - the processor core - any
> > > > instruction is atomic on all processors I know.
>
> > > Not necessarily.
>
> > > * The instructions that take long time to execute could be interrupte=
d
> > > in the middle. Such as chain operations or integer division.
>
> > Division? I have not seen that being interruptible. Where do they do
> > that?
>
> As I recall on the ST10/C167 both division ans multiplication
> operations are interruptable. =A0If you wish to use those operations
> withing an interrupt you must store extra context.
>
> Robert
What a nightmare stack frame to handle... :-). On the TI 54xx division
not adding latency is solved in a very elegant way - it is done in a
loop by a "subtract conditionally" opcode (don't remember the exact
name, I wrote an assembler for it but that was almost 10 years ago).
Anyway, it uses the loop mode execution so in effect the division
is really fast - 16 cycles for 32/16 IIRC (or was it for 16/16) - but
interruptible with no horror stack frames.
Dimiter
Reply by Robert Adsett●February 4, 20102010-02-04
On Feb 3, 5:33=A0pm, Didi <d...@tgi-sci.com> wrote:
> On Feb 3, 9:56=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> > Didi wrote:
> > > In the context of a single bus master - the processor core - any
> > > instruction is atomic on all processors I know.
>
> > Not necessarily.
>
> > * The instructions that take long time to execute could be interrupted
> > in the middle. Such as chain operations or integer division.
>
> Division? I have not seen that being interruptible. Where do they do
> that?
As I recall on the ST10/C167 both division ans multiplication
operations are interruptable. If you wish to use those operations
withing an interrupt you must store extra context.
Robert
Reply by Paul Keinanen●February 4, 20102010-02-04
On Thu, 4 Feb 2010 03:57:53 +0000 (UTC), Przemek Klosowski
<przemek@tux.dot.org> wrote:
>On Wed, 03 Feb 2010 14:33:20 -0800, Didi wrote:
>
>>> I never count on implicit atomicity of any operation.
>>
>> Well neither do I, but things are not that bad. I have developed an
>> almost subconscious feeling when and what I need of that, so much so I
>> even forgot the obvious case of crossing page boundary
>
>Of course it depends on the architecture. One of the original design
>reasons for the RISC architectures was the unpredictability and complex
>behavior of long CISC instructions. VAX instruction set for instance
>allowed a single instruction that touched up to 52 (!!!) pages, with that
>many page faults being the worst case:
>
>http://pupgg.princeton.edu/cdrom12/html/ssb71/6258/6048p066.htm
Just wondering, how they have arrived at this figure. The character
string instructions can touch far more pages than that and those
instructions are definitely intended to be interruptible, by polluting
registers R0..R5, even if these registers are not referenced in the
instruction, in order to saving pointers and remaining counts at the
interrupt.
I tried to count the maximum number of page faults during operand
evaluation, before any character string or packed decimal access
starts and reached 20 pages on a six operand instruction (three
address+count pairs). This assumes indirect addressing on all
operands, in which each pointer is on a page boundary and the three
byte counts are on page boundaries too and of course the instruction
on a page boundary too (2+3x(2+4)) pages. Of course, more page faults
may occur, when the actual byte or packed decimal processing starts.
Reply by David Brown●February 4, 20102010-02-04
On 03/02/2010 23:33, Didi wrote:
> On Feb 3, 9:56 pm, Vladimir Vassilevsky<nos...@nowhere.com> wrote:
>> Didi wrote:
>>> In the context of a single bus master - the processor core - any
>>> instruction is atomic on all processors I know.
>>
>> Not necessarily.
>>
>> * The instructions that take long time to execute could be interrupted
>> in the middle. Such as chain operations or integer division.
>
> Division? I have not seen that being interruptible. Where do they do
> that?
>
On some of the larger 68k cores, long microcoded operations could be
interrupted. That included division, multiple register moves, and a few
others. I haven't used these myself (only the CPU32, then ColdFire), so
I don't remember the details. But the exception stack frame had many
variants, depending on which internal cpu registers needed to be saved
and restored so that the instruction could be continued on a return from
exception.
Such messy complications were dropped in the later 68k cores, and of
course avoided altogether in the ColdFire.
Reply by Thad Smith●February 4, 20102010-02-04
Niklas Holsti wrote:
> brOS wrote:
>> Thad wrote:
>>> Some kernel operations need to be done with interrupts disabled. After
>> your
>>> task suspends itself on the semaphore, the kernel should not be
>> interruptable
>>> until the next (idle) task is running. Generally, interrupts are
>> reenabled by
>>> executing a RETI, which restores the status register, including the
>>> GIE interrupt enable bit. At that point your PC has been popped.
>>
>> But, is the RETI instruction atomic? I think it s not?
RETI is atomic. It is executed to completion before an interrupt can occur.
> Some quotes from the MSP430 description in the "MSP430x4xx Family" (TI
> document SLAU056D):
...
> Page 3-40:
>
> "The instruction following the enable interrupt instruction (EINT) is
> always executed, even if an interrupt service request is pending when
> the interrupts are enable."
>
> It thus seems to me that the EINT/RETI pair work as is common: after an
> interrupt is enabled, the response to a new or pending interrupt request
> is delayed until the RETI has completed.
There is no need for the EINT since the maskable interrupts are enabled by
restoring the status register, which is part of the RETI.
--
Thad
Reply by Przemek Klosowski●February 3, 20102010-02-03
On Wed, 03 Feb 2010 14:33:20 -0800, Didi wrote:
>> I never count on implicit atomicity of any operation.
>
> Well neither do I, but things are not that bad. I have developed an
> almost subconscious feeling when and what I need of that, so much so I
> even forgot the obvious case of crossing page boundary
Of course it depends on the architecture. One of the original design
reasons for the RISC architectures was the unpredictability and complex
behavior of long CISC instructions. VAX instruction set for instance
allowed a single instruction that touched up to 52 (!!!) pages, with that
many page faults being the worst case:
http://pupgg.princeton.edu/cdrom12/html/ssb71/6258/6048p066.htm
Reply by Didi●February 3, 20102010-02-03
On Feb 3, 9:56=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Didi wrote:
> > In the context of a single bus master - the processor core - any
> > instruction is atomic on all processors I know.
>
> Not necessarily.
>
> * The instructions that take long time to execute could be interrupted
> in the middle. Such as chain operations or integer division.
Division? I have not seen that being interruptible. Where do they do
that?
>
> * Reads and writes of the operands that are wider then the CPU bus (such
> as 64-bit reads and writes) could be interrupted in between the bus cycle=
s.
Only in the context Paul reminded me - crossing a page boundary. Other
than that, I don't know what could interrupt it. Not on the
architectures
I know, that is - power, 68k, 68xx, TI 54xx.
>
> * Read/write bursts can be interrupted.
>
> * Bus interface unit can shuffle the order of bus operations. In some
> cases this could be not transparent to the CPU.
>
> I never count on implicit atomicity of any operation.
Well neither do I, but things are not that bad. I have
developed an almost subconscious feeling when and what
I need of that, so much so I even forgot the obvious case
of crossing page boundary in my earlier post :-).
On power, using lwarx/stwcx. does the job nicely for me wherever
needed; too bad they messed the e600 core up so it can be
hung by some case of these opcodes (which are user level,
mind you). Hope the newer QorIQ (who made this name up?...)
are cleaner, I am eyeing one of these.
Dimiter
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
Reply by Didi●February 3, 20102010-02-03
On Feb 3, 11:35=A0pm, Paul Keinanen <keina...@sci.fi> wrote:
> On Wed, 3 Feb 2010 11:04:10 -0800 (PST), Didi <d...@tgi-sci.com> wrote:
> >In the context of a single bus master - the processor core - any
> >instruction
> >is atomic on all processors I know.
>
> On =A0a processor that supports virtual memory, each memory (byte)
> reference might be interrupted.
>
> For this reason, the hardware will often require that the interlocked
> data is 32/64 bit aligned, in order to be atomic.
Indeed - at least on Power it will take crossing a page boundary
to cause a DSI or sort of exception. Handling it may cause a task
switch (at least in DPS it can), and the accessed data of the page
which succeeded can be accessed by another task prior to the
interrupted
one gains access to the second half of the access so you are right.
I was thinking small cores for once as the original question
was in the context of such one IIRC and I completely forgot of
what I was actually doing all day (I currently live in Power :-) ).
Dimiter
Reply by Paul Keinanen●February 3, 20102010-02-03
On Wed, 3 Feb 2010 11:04:10 -0800 (PST), Didi <dp@tgi-sci.com> wrote:
>In the context of a single bus master - the processor core - any
>instruction
>is atomic on all processors I know.
On a processor that supports virtual memory, each memory (byte)
reference might be interrupted.
For this reason, the hardware will often require that the interlocked
data is 32/64 bit aligned, in order to be atomic.
Reply by Vladimir Vassilevsky●February 3, 20102010-02-03
Didi wrote:
> In the context of a single bus master - the processor core - any
> instruction is atomic on all processors I know.
Not necessarily.
* The instructions that take long time to execute could be interrupted
in the middle. Such as chain operations or integer division.
* Reads and writes of the operands that are wider then the CPU bus (such
as 64-bit reads and writes) could be interrupted in between the bus cycles.
* Read/write bursts can be interrupted.
* Bus interface unit can shuffle the order of bus operations. In some
cases this could be not transparent to the CPU.
I never count on implicit atomicity of any operation.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com