-- code test sccode00
#INCLUDE "linkaddr.inc"
#INCLUDE "wiserver.inc"
#USE "sccode00.c5h"
CHAN OF SP from.host, to.host, VAL INT memory:
PROCESSOR 0 T425
PLACE from.host AT link0.in :
PLACE to.host AT link0.out :
PAR
code (from.host, to.host, memory)
Produces the ERROR symbol VAL is an invalid variable name
for the code fragment from WISERVER
#INCLUDE "wiserver.inc"
#USE "wiserver.lib"
PROC code (CHAN OF SP from.isv, to.isv, []INT memory)
SEQ
etc .....
It may very well be an invalid variable name, but it is a form copied
directly from the OCCAM Tools Set User Manual and VAL is a reserved key word
Give me a break.
will someone who is running WISERVER and has compiled to .btl format using
iconf and CSA tools, OR who sees why the .pgm file dosn't work please set
me on the path to nervana, or shoot me.
Those interested in forming a 12-step OCCAM support group may also reach
me at c...@indirect.com
The above is not valid occam2. You cannot declare variables and channels
in the same statement since they have different types. The type of
CHAN OF SP (a communications channel) is not the same as VAL INT (a
constant integer type).
What you should do is:
CHAN OF SP from.host, to.host:
VAL INT memory:
The error message, although completely precise, doesn't help much in this
case.
>[...]
>It may very well be an invalid variable name, but it is a form copied
>directly from the OCCAM Tools Set User Manual and VAL is a reserved key word
>Give me a break.
The examples can't be completely correct if this is the case.
Dave
I think you should have written instead of the upper line:
CHAN OF SP from.host, to.host :
VAL INT memory :
Moreover if you look at your code bit below it seems like 'code' expects
an array of INTs, so you should have written:
VAL [1]INT memory :
> PROCESSOR 0 T425
> PLACE from.host AT link0.in :
> PLACE to.host AT link0.out :
> PAR
> code (from.host, to.host, memory)
>
>
> Produces the ERROR symbol VAL is an invalid variable name
>
> for the code fragment from WISERVER
>
> #INCLUDE "wiserver.inc"
> #USE "wiserver.lib"
> PROC code (CHAN OF SP from.isv, to.isv, []INT memory)
> SEQ
> etc .....
>
> It may very well be an invalid variable name, but it is a form copied
> directly from the OCCAM Tools Set User Manual and VAL is a reserved key word
> Give me a break.
>
> will someone who is running WISERVER and has compiled to .btl format using
> iconf and CSA tools, OR who sees why the .pgm file dosn't work please set
> me on the path to nervana, or shoot me.
The above should work.. (works for me...)
>
> Those interested in forming a 12-step OCCAM support group may also reach
> me at c...@indirect.com
>
>
>
>
Hope that this helped...
Andres
------------------------------------------------------------------------------
Andres Kruse | NIKHEF - National Institute for Nuclear Physics and
A.K...@nikhef.nl | High-Energy Physics, Amsterdam, The Netherlands
OH, MY GOD !!! Big Mistake...
should have been
CHAN OF SP from.host, to.host :
INT memory :
>
> Moreover if you look at your code bit below it seems like 'code' expects
> an array of INTs, so you should have written:
>
> VAL [1]INT memory :
should have been
[1]INT memory :
>
>
> > PROCESSOR 0 T425
> > PLACE from.host AT link0.in :
> > PLACE to.host AT link0.out :
> > PAR
> > code (from.host, to.host, memory)
> >
> >
> > Produces the ERROR symbol VAL is an invalid variable name
> >
> > for the code fragment from WISERVER
> >
> > #INCLUDE "wiserver.inc"
> > #USE "wiserver.lib"
> > PROC code (CHAN OF SP from.isv, to.isv, []INT memory)
> > SEQ
> > etc .....
> >
> > It may very well be an invalid variable name, but it is a form copied
> > directly from the OCCAM Tools Set User Manual and VAL is a reserved key word
> > Give me a break.
> >
> > will someone who is running WISERVER and has compiled to .btl format using
> > iconf and CSA tools, OR who sees why the .pgm file dosn't work please set
> > me on the path to nervana, or shoot me.
>
> The above should work.. (works for me...)
but now it should....
>
> >
> > Those interested in forming a 12-step OCCAM support group may also reach
> > me at c...@indirect.com
> >
> >
> >
> >
>
> Hope that this helped...
>
> Andres
>
> ------------------------------------------------------------------------------
> Andres Kruse | NIKHEF - National Institute for Nuclear Physics and
> A.K...@nikhef.nl | High-Energy Physics, Amsterdam, The Netherlands
>
>
>
-- Andres
CHAN OF SP fs,ts:
INT memory:
also tried
CHAN OF SP fs,ts:
[1]INT memory:
both produced the message -- variables of type INT may not be declared at
configuration level.
It's a shame that I don't have new tools! I'm forced, at least for the
moment to use D705 tools.
Perhaps the way out of this dilemma is to accept and follow the lead given
by the Free Software Foundation and port GCC over to the transputer, with
appropriate hacks for parallism. That, together with a port of WISERVER
over to X windows running under Linux would be a proud, and righteous
solution.
PS for those of you who have PCs and havn't tried Linux yet. Do. It is
very, very impressive.
I am c...@indirect.com
Apocryphal story:
Richard Stallman was asked about gcc and transputers but his reply
was apparently that it was very difficult since gcc was designed for
many-register based (mostly RISC) processor machines and the
transputer, being a small stack machine wouldn't map easily onto that
architecture.
Having said that, there is a gcc implementation for transputers
written as a student project by undergraduates at the University of
Southampton for the Helios operating system. You can ftp the very
large (2.8M) compressed tar file as:
/parallel/software/southampton/gcc-helios-t8.tar.Z
from
unix.hensa.ac.uk
and check it out if you wish. It may be some kind of pointer to
people interested in developing this -- but it would be a lot of
work.
Dave
>Apocryphal story:
>Richard Stallman was asked about gcc and transputers but his reply
>was apparently that it was very difficult since gcc was designed for
>many-register based (mostly RISC) processor machines and the
>transputer, being a small stack machine wouldn't map easily onto that
>architecture.
>Having said that, there is a gcc implementation for transputers
>written as a student project by undergraduates at the University of
>Southampton for the Helios operating system.
Nick Stephen was my student when he did this work. He uses a small
region of internal memory as a "register set" for each thread, and lets
gcc target this in the usual RISC way. It's a bit slow, the
floating-point support is untested, the short support is missing and
it's based on gcc1.37. For an undergrad project, he did a real good
job. He's now porting Chorus onto transputers...
Denis Nicole
d...@ecs.soton.ac.uk
Denis Nicole writes:
| > Having said that, there is a gcc implementation for transputers
| > written as a student project by undergraduates at the University of
| > Southampton for the Helios operating system.
|
| Nick Stephen was my student when he did this work. He uses a small
| region of internal memory as a "register set" for each thread, and lets
| gcc target this in the usual RISC way. It's a bit slow, the
| floating-point support is untested, the short support is missing and
| it's based on gcc1.37. For an undergrad project, he did a real good
| job. He's now porting Chorus onto transputers...
This idea of mapping registers into memory is interesting.
Do you know if we can get a copy (either paper or by ftp) of
this undergrad project thesis ?
Thanks in advance,
Christian
--
#include <disclamer.h>
Christian Fabre, OSF Research Institute,
2 avenue de Vignate, 38610 Gieres, France.
Tel: +33 76.63.48.90 -- Fax: +33 76.51.05.32 -- fa...@gr.osf.org
It is true that GCC is not fitting very well for the transputer
architecture. The major two obstacles are the stack-like register
model and the lack of registers. Both are now somehow coped with.
Recently the compiler started to produce at least something except
core dumps (:-), although the code is still not too good. The
largest program compiled (and running) today is the C beautifier from
an old BSD 2.9 distribution; it is about 350 lines long.
However, the port is still a long way from becoming really usable.