🚀 go-pugleaf

well.... I've found the "problem". Here is a segment of my code:

  SEQ messages.to.send=0 FOR Min(clockwise, anticlockwise)
    SEQ
      PAR
        ... send data to.clockwise
        ... receive data from.clockwise
        ... send data to.anticlockwise
        ... receive data from.anticlockwise
      ... update some information

  IF
    clockwise = anticlockwise
      SKIP
    clockwise = (anticlockwise+1)
      ... send/receive data clockwise
    clockwise = (anticlockwise-1)
      ... send/receive data anticlockwise



The COMPILER ERROR 'occurred' at the IF statement. But, many hours later, I discover
that the compiler was totally unable to cope with the replicated SEQ statement having
the count defined by a function... ;-(

Michael

In article <5593@m1.cs.man.ac.uk> bane@vtx.ma.man.ac.uk writes:
>Does anybody know what the 
>
>   Error 7014:2240  COMPILER ERROR : please report
          ^^^^^^^^^
          Can this be segment-offset on the IBM pc?????????

means? Or whom to report it to?
>
>Thanks in advance,
>Michael Bane
>Numerical Analysis and Computing
>Manchester University
>
>Tel: 061-275 5800/5825
What compler, who is the vendor????

Jan (jan@neuroinformatik.ruhrunibochum.de) asks with regard to my earlier mailing
about an compiler error:

> According to the occam reference manual, the count can ba an expression, and 
> an expression can certainly contain a function. Are you sure that your
> function doesn't evaluate to a negative value at compile time. (Although
> I'm not sure the occam compiler actually does the obvious thing and evalute
> such a function at compile time...)

well the function was the Min of 2 integers, neither of which (as far as the SC knows)
is a compile-time constant (or known at compile time).



I received this reply from Tony (arc1@uk.ac.ukc) which might shed a little light on
the subject:

> Michael,
> Ah yes, I think there is a bug to do with return values on
> the stack getting nobbled in FUNCTION calls.  Often having a
> non-trivial expression (i.e. anything more complicated than
> a varaible name or a constant) in the RETURN line of the
> function will cause this, or cause corrupted data values.
> This blew up one of our users.

[NB: my function call only had a single INT value to be RETURNed]


To finish this discussion off, I'd just like to point out that I'm amazed that I
received the message COMPILER ERROR - please report which, to me, implies that it is
the compiler (and thus not, necessarily, my code) that was in deep trouble. Doubly
surprizing that the compiler failed in such a normal/straightforward piece of code.


All the best, 
Michael


PS: Do many people still use occam? I was told recently by a systems person on a
transputer machine that nobody uses occam anymore...

In article <5613@m1.cs.man.ac.uk> bane@vtx.ma.man.ac.uk) writes:

>     SEQ messages.to.send=0 FOR Min(clockwise, anticlockwise)
>[rest of code eliminated]
>
>   The COMPILER ERROR 'occurred' at the IF statement. But, many hours later, I
>   discover that the compiler was totally unable to cope with the replicated
>   SEQ statement having the count defined by a function... ;(
>
>   Michael

According to the occam reference manual, the count can ba an expression, and 
an expression can certainly contain a function. Are you sure that your
function doesn't evaluate to a negative value at compile time. (Although
I'm not sure the occam compiler actually does the obvious thing and evalute
such a function at compile time...)

Jan Vorbrueggen, jan@neuroinformatik.ruhrunibochum.de

I have found the same bug in the compiler and the only way to work around that
was to evaluate the function in a VAL expression.

--
                                    Rudnei Dias da Cunha
                                        rdd@ukc.ac.uk
                       Computing Lab, University of Kent at Canterbury
                          Canterbury, Kent  CT2 7NF, United Kingdom

> I have found the same bug in the compiler and the only way to work around that
> was to evaluate the function in a VAL expression.

To save me (and possibly you/others) relearning the wheel (the HARD way) could
somebody drop the net a pointer to a list of know compiler bugs (etc)


Michael.

I haven't touched occam for nearly three years and I'm amazed those bugs
are still in the Inmos compiler. Haven't they fixed 'em yet!
-- 
Andy Newman (andy@research.canon.oz.au)		"int - God's own type"

>
>   To save me (and possibly you/others) relearning the wheel (the HARD way)
>   could somebody drop the net a pointer to a list of know compiler bugs (etc)
>

Beat hard upon your distributor  there is a public, published bug list
from INMOS for all their software products. It took me about half a year
to get it out of parsytec (by that time I had found three serious code
generation bugs in the occam compiler, two of which were documented).

There was indeed a bug in the compiler with the return value of functions,
which turned up in two cases: more than 3 return arguments of one type
(overflow of the register stack, but caller and callee part of the code
generator had different ideas of what to do in that case); the RETURN
line itself called a function returning, eg, a float  the compiler
doesn't distinguish properly between the integer and floating evaluation
stack. A victim of that last bug is the wellknown function RAN 
as supplied with the compiler, it will never work!

But I haven't had the compiler complain in such a way as you report 
maybe you're lucky, because I spent days trying to find out what went
wrong, including looking at the disassembled code.
(The numbers after the error, BTW, are first an error number you can
look up in the manual and then an errorspecific number of which there
is exactly no docuumentation in all cases :))

Good hunting, Jan

jan@neuroinformatik.ruhrunibochum.de

In article <5634@m1.cs.man.ac.uk>, bane@vtx.ma.man.ac.uk writes:

> To save me (and possibly you/others) relearning the wheel (the HARD way) could
> somebody drop the net a pointer to a list of know compiler bugs (etc)

The inmos.com e-mail archive-server (archive-server@inmos.com) holds
"selected" INMOS software bulletins (bug reports & workarounds). I
don't know how up-to-date this is - most seem to date from 1990. I
think the index request message format is "send bulletins/Index"

-- 
Scott Telford, Dept of Computer Science,      electric mail: s.telford@ed.ac.uk
University of Edinburgh, Mayfield Rd, Edinburgh, EH9 3JZ, UK.
------- Rollin' over like a big, big cloud/Walkin' out in the Big Sky! --------

In article <41199@skye.dcs.ed.ac.uk> s.telford@ed.ac.uk (Scott Telford) writes:

   The inmos.com e-mail archive-server (archive-server@inmos.com) holds
   "selected" INMOS software bulletins (bug reports & workarounds). I
   don't know how up-to-date this is - most seem to date from 1990. I
   think the index request message format is "send bulletins/Index"

The Inmos archive server holds some interested programs, but Scott is
right about the bug reports there is nothing up to date. You would
expect this archive to be like the letters page of a journal, helpful
but not authoritative. However it seems to be just as hopelesly old
and incomplete as Inmos's printed errata sheets.

I would expect to much of it,

--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk

Woops last line of my posting messed up. I should have read:

I wouldN'T expect too much of it,

--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk