[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Transputer - schools
Given that you are already working down at the opcode level, do you see any possibility of a similar approach (or other) to getting a Helios shell up and flying on the Arm ? Would this be a simpler task than Kroc ?
I notice that the bits of source I have refer to the Arm, thought it was probably very different then.
I found the Helios shell made life very easy when joining Apl processes together on the Transputer.
From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of Ruth Ivimey-Cook
Sent: 27 June 2013 23:05
To: Larry Dickson; occam-com@xxxxxxxxxx
Subject: Re: Transputer - schools
Larry Dickson wrote:
> This is probably a lot of work, but would it be possible to revisit the Transterpreter? In the INMOS Compiler Writer's Guide, it shows the assembly commands coming in structured clumps, each corresponding to a very clear occam primitive. Since occam is such a flat language, it ought to be possible to go through output of the occam compiler and recognize these clumps, thus decompiling to the point of exposing the essential process and communication structure.
When I was working on KRoC, this was the main thing I concluded needed to be done; KRoC (at the time) relied on translating one transputer instruction at a time, and my experience with ARM was that it was horrendously inefficient to do that, for various architectural reasons.
I started on a revamp of the KRoC backend that would enable peephole optimisation of the transputer code as well as easier optimisation of the translated arm code, but "stuff happened", amongst which the ETC code updates to KRoC which rendered a lot of what I had been doing unusable in a longer term, and so I stopped.
The code, as far as it went, is on www.ivimey.org, in three variations.
I implemented most of the integer transputer opcodes, and some of the FP ones. The problem that wasn't solved was the need for literal pools, which became a chronic headache.
Hope this helps; it would be good if the code could be taken up and forward, though of course many things have changed since then.
Software Manager& Engineer
Tel: 01223 414180