a short moan about compilers...
Pete French
compilers. we had a very nice man come to sell us some T9000's yesterday.
I would like to buy 10 - 12 of these parts. Unfortunately unless I want to
program them in machine code by hand it seems I wont be able to use them
because inmos aren't actually providing compilers for them. The compilers will
run on SUN's and PC's. Thats it. No more of the "just port the iserver and you
can run the toolkit wherever you want".
This pisses me off a _lot_. I've waited a long time for these chips and now I
won't be able to use them (unless of course I'm willing to buy a SUN or a PC).
I hope somebody from imos is going to shoot me down in flames and say that I've
got my facts all wrong and they will be providing native compilers, but sadly
I doubt it.
-pete french.
--
-Pete French. (the -bat. ) -+ Wanted : Female hitching partner. Must have
| looks to stop lorries at a single glance and
Adaptive Systems Engineering | be able to sleep rough without spoiling her
+- makeup or hair. Only UK goths need apply. :-)
Stephen Doyle
>- principally the fact that inmos are apparently abandoning the native
>compilers. we had a very nice man come to sell us some T9000's yesterday.
>I would like to buy 10 - 12 of these parts. Unfortunately unless I want to
>program them in machine code by hand it seems I wont be able to use them
>because inmos aren't actually providing compilers for them. The compilers will
>run on SUN's and PC's. Thats it. No more of the "just port the iserver and you
>can run the toolkit wherever you want".
We have certainly abandoned the "native" compilers (i.e. the compiler runs
on a transputer) as a clear response to customer demands. This is not
INMOS trying to line the pockets of Intel or SPARC manufacturers. It is a
response to the demand to have tools running on nice fast PC's and workstations
rather than having to download your compiler image of say 6-700kb via a link
adapter at 1-200kb/s before even starting to compile. We know that there is
a minority of customers who have been using the "native" compilers, we cannot
support an option that has been proven unpopular to the majority of the
customer base hence native mode compilers are no more.
There are good advantages to be gained by systems developers through this
process of targeting and rationalisation. For instance we have been releasing
advanced tools for transputer development over the last year including
graphical user interface debugger Inquest and profiling tools running on the
Sun and currently on field trials at major accounts for the PC. We would
never have been able to achieve these desirable products if engineering
resources were focused on native mode tools.
So PC and Sun hosted compilers, linkers, ... debugging and profiling tools
will be available for T9000 immediately on commercial availability
of hardware.
>
>This pisses me off a _lot_. I've waited a long time for these chips and now I
>won't be able to use them (unless of course I'm willing to buy a SUN or a PC).
I hope this won't come as too much of a shock but there are rather more PC's
in the world than transputers and most customers expect to run packaged
applications on the PC not on a transputer. Look on the bright side, at least
whilst you've been waiting PC prices have plummeted.
Steve
Steve Doyle, Software Marketing, INMOS Ltd | Tel +44 454 616616
1000 Aztec West | Fax +44 454 617910
Almondsbury | UK: ste...@inmos.co.uk
Bristol BS12 4SQ, UK | US: ste...@inmos.com
Jerzy Michal Pawlak
In article <1993Nov17....@inmos.co.uk>, ste...@inmos.co.uk (Stephen Doyle) writes:
> [...]
>
>So PC and Sun hosted compilers, linkers, ... debugging and profiling tools
>will be available for T9000 immediately on commercial availability
>of hardware.
>
>
>I hope this won't come as too much of a shock but there are rather more PC's
>in the world than transputers and most customers expect to run packaged
>applications on the PC not on a transputer. Look on the bright side, at least
>whilst you've been waiting PC prices have plummeted.
>
Up till now I nicely avoided the need for other machines. Now you tell me that
if I want to move to T9000, I'll have to buy a PC, move my whole development
there, and move my compiled code back to VAX to use it? Nice idea... I know
there are many PC's in the world, but it doesn't mean I want to have one...
--
Michal (paw...@zeubac.desy.de)
Rob Kurver
>In article <1993Nov17....@inmos.co.uk>, ste...@inmos.co.uk (Stephen Doyle) writes:
>>So PC and Sun hosted compilers, linkers, ... debugging and profiling tools
>>will be available for T9000 immediately on commercial availability
>>of hardware.
>>in the world than transputers and most customers expect to run packaged
>>applications on the PC not on a transputer. Look on the bright side, at least
>>whilst you've been waiting PC prices have plummeted.
>Thank you very much. My application is a VAX diving a transputer network.
>Up till now I nicely avoided the need for other machines. Now you tell me that
>if I want to move to T9000, I'll have to buy a PC, move my whole development
>there, and move my compiled code back to VAX to use it? Nice idea... I know
>there are many PC's in the world, but it doesn't mean I want to have one...
We recognize all the world is not a Sun or PC, and will have PC and Sun
hosted, as well as native development systems available for the T9000 on
commercial availability of hardware. And already for the T4/T8 series.
No occam as of yet, though -- just ANSI C, Parallel C, K&R C, Fortran 77,
Pascal and Modula-2.
One of the nice things of providing a full POSIX environment is the ability
to quickly and easily provide native tools...
Please contact me by email for more info.
Rob
--
PACT Rob Kurver
Foulkeslaan 87 r...@pact.nl
2625 RB Delft ph: +31 15 616864
The Netherlands fax: +31 15 610032
Paul Walker
>In article <1993Nov16....@ohm.york.ac.uk> pe...@ohm.york.ac.uk (Pete
> French) writes:
>>- principally the fact that inmos are apparently abandoning the native
>>compilers. we had a very nice man come to sell us some T9000's yesterday.
>>I would like to buy 10 - 12 of these parts. Unfortunately unless I want to
>>program them in machine code by hand it seems I wont be able to use them
>>because inmos aren't actually providing compilers for them. The compilers will
>>run on SUN's and PC's. Thats it. No more of the "just port the iserver and you
>>can run the toolkit wherever you want".
>
>We have certainly abandoned the "native" compilers (i.e. the compiler runs
>on a transputer) as a clear response to customer demands.
This is a distortion of customer demands. Customers may have asked for
compilers running on PCs and Suns. That is in no way the same thing
as them asking that they no longer run on transputers.
>This is not
>INMOS trying to line the pockets of Intel or SPARC manufacturers. It is a
>response to the demand to have tools running on nice fast PC's and workstations
So INMOS is saying loud and clear "Our processor is useless, you need to
use a decent processor to do a real job such as compiling." The message
is also loud and clear that real jobs can not gain advantage from using
more than one processor. Wrong, but that is what INMOS' software
product policy implies.
>rather than having to download your compiler image of say 6-700kb via a link
>adapter at 1-200kb/s before even starting to compile.
So how about solving the real problem, as several of the independent
transputer board manufacturers have done. (Sorry I have to admit my own
responsibility for the B004/B008 interface --- it was good at the
time but others were responsible for its not being upgraded.) Some
of the independent designs offer a fast interface to disk, so that
the file transfers do not even go across the PC's bus.
>We know that there is
>a minority of customers who have been using the "native" compilers, we cannot
>support an option that has been proven unpopular to the majority of the
>customer base hence native mode compilers are no more.
What has been clear for the last ten years, ever since the Sage
development system (about 1983?), that WHATEVER host computer
is chosen for the development system, it is the wrong choice.
>
>There are good advantages to be gained by systems developers through this
>process of targeting and rationalisation. For instance we have been releasing
>advanced tools for transputer development over the last year including
>graphical user interface debugger Inquest and profiling tools running on the
>Sun and currently on field trials at major accounts for the PC. We would
>never have been able to achieve these desirable products if engineering
>resources were focused on native mode tools.
On the Sun, or on an X-tele? On the PC, or on Windows?
>So PC and Sun hosted compilers, linkers, ... debugging and profiling tools
>will be available for T9000 immediately on commercial availability
>of hardware.
>
>>
>>This pisses me off a _lot_. I've waited a long time for these chips and now I
>>won't be able to use them (unless of course I'm willing to buy a SUN or a PC).
>
>I hope this won't come as too much of a shock but there are rather more PC's
>in the world than transputers and most customers expect to run packaged
>applications on the PC not on a transputer. Look on the bright side, at least
>whilst you've been waiting PC prices have plummeted.
Sorry Steve. As much as anyone who has ever been associated with
transputers, I would (still) like to see them succeed. But with support
from transputer marketing as damning as yours, is it possible?
I hope the links will not be suffocated in the same way.
Paul
Brendan Murphy
(Stephen Doyle) writes:
>We have certainly abandoned the "native" compilers (i.e. the compiler
>runs on a transputer) as a clear response to customer demands. This is
>not INMOS trying to line the pockets of Intel or SPARC manufacturers.
>It is a response to the demand to have tools running on nice fast PC's
>and workstations rather than having to download your compiler image of
>say 6-700kb via a link adapter at 1-200kb/s before even starting to
>compile.
You could use faster link interface hardware...
>We know that there is a minority of customers who have been using the
>"native" compilers, we cannot support an option that has been proven
>unpopular to the majority of the customer base hence native mode
>compilers are no more.
Somewhat draconian, don't you think?
Given that you already have a cross-compiler, surely porting the
compiler itself would be straightforward? Would this not be a painless
concession to those who prefer to use a native compiler, albeit without
the support of a graphical debugger, etc?
Brendan
--
********************************************************************************
Brendan Murphy bre...@buck.ac.uk
Department of Computer Science Tel: 44 (0)280 814080
University of Buckingham, Buckingham, MK18 1EG, UK Fax: 44 (0)280 822245
********************************************************************************
Denis Nicole
In article <1993Nov17....@inmos.co.uk> ste...@inmos.co.uk
(Stephen Doyle) writes:
>We have certainly abandoned the "native" compilers (i.e. the compiler
>runs on a transputer) as a clear response to customer demands. This is
>not INMOS trying to line the pockets of Intel or SPARC manufacturers.
>It is a response to the demand to have tools running on nice fast PC's
>and workstations rather than having to download your compiler image of
>say 6-700kb via a link adapter at 1-200kb/s before even starting to
>compile.
This really isn't a problem if you have a properly designed interface to
your IBM. We (with IBM Winchester) built a decent link interface to
our IBM3090 and had no problem with download or file access times. It
is, however, a bit of a pain that our IBM used EBCDIC and we had to
build a folding XEDIT...
Denis Nicole
d...@ecs.soton.ac.uk
Pete French
> compiler itself would be straightforward? Would this not be a painless
> concession to those who prefer to use a native compiler, albeit without
> the support of a graphical debugger, etc?
Yes, in fact porting the compiler is very, very easy as anyone who has
seen the source will tell you. It's very nicely written in ANSI-C and
tends to compile under GCC with the minimum of difficulty. I got a running
executable on my NeXT in less than an afternoon - and that was without any
experience or documentation, just working from the Makefiles and the source.
It's not a hard job to make a binary and put it on a disk.