Re: failure due to compiler?

Eric Hamilton <eric@gyst.com>
23 Jul 1996 23:29:48 -0400

          From comp.compilers

Related articles
[23 earlier articles]
Re: failure due to compiler? iwm@doc.ic.ac.uk (Ian Moor) (1996-07-20)
Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-20)
Re: failure due to compiler? jgllgher@maths.tcd.ie (Dara Gallagher) (1996-07-20)
Re: failure due to compiler? ok@cs.rmit.edu.au (1996-07-22)
Re: failure due to compiler? rfg@monkeys.com (1996-07-22)
Re: failure due to compiler? leew@micrologic.com (Lee Webber) (1996-07-23)
Re: failure due to compiler? eric@gyst.com (Eric Hamilton) (1996-07-23)
Re: failure due to compiler? davidg@genmagic.com (1996-07-23)
Re: failure due to compiler? davidg@genmagic.com (1996-07-24)
Re: failure due to compiler? jmccarty@sun1307.spd.dsccc.com (1996-07-26)
Re: failure due to compiler? davidg@genmagic.com (1996-07-31)
Re: failure due to compiler? feliks@carlstedt.se (1996-07-31)
| List of all articles for this month |
From: Eric Hamilton <eric@gyst.com>
Newsgroups: comp.compilers
Date: 23 Jul 1996 23:29:48 -0400
Organization: Compilers Central
References: 96-07-041 96-07-100 96-07-148
Keywords: errors, Fortran, comment

Hi


We once had a problem with a Fortran compiler, that while it generated
correct code, did not generate code which we could use. What happened is
that we were using .AND./.OR. to control interlocking in a real time
environment. The code that was generated was something like this:


                load r1 flag_word
                and r1 mask
                store r1 flag_word


Although this works in a "normal" case, in a real-time interlocking case
an interrupt can occur between any two instructions (here anywhere after
the "load" and before the "store", i.e. either side of the "and") and
control may go over to a higher priority task. That task may also modify
the same flag_word, and when control returns to the original task, then
the "old" flag_word gets stuck back in memory (which by now, may or not
be, similar to what the higher priority task just did to it.)


Fortunately we checked the assembly output of the compiler before we had
written too much code using interlocks. (What we ended up doing was to
write some subroutines in assembly that: locked out interrupts, did their
modifications of the flag_word and then released interrupts.)


Isn't real time, multitasking fun?


bye...................eric
[I'm not sure I would call that a compiler error unless the compiler vendor
promised you thread safe code. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.