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) |
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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.