Transputer patents, licences and copyrights

Transputer patents, licences and copyrights

Post by Nm » Thu, 15 Apr 2004 01:02:41



When do the patents for the original transputer chips expire, allowing
3rd party study, redesign, reuse and/or replication. I seem to
remember IBM patents for the original desktop PC reaching their expiry
(15-25years) and HK, MidEast etc entering (or creating) the clone PC
market.

Does the same apply to patents on transputer technology. What are we
allowed to create and how closly can it replicate to original
technology.

Afterall it is obvious that SGS Thomson (STelectronics) have seen no
market specfically for transputers, only the link technology (embedded
in ST20s). Further as the patents holders they are no doubt going to
want to control and profit from, but not fund any new or replicative
transputer innovation.

So when can I legally start producing my 100% compatible opencore
transputer?

Nme. God Bless.

P.S. Can someone email Pete Feeney for me. I have lost contact.

 
 
 

Transputer patents, licences and copyrights

Post by Alec Cawle » Thu, 15 Apr 2004 02:19:57




Quote:>When do the patents for the original transputer chips expire, allowing
>3rd party study, redesign, reuse and/or replication. I seem to
>remember IBM patents for the original desktop PC reaching their expiry
>(15-25years) and HK, MidEast etc entering (or creating) the clone PC
>market.

>Does the same apply to patents on transputer technology. What are we
>allowed to create and how closly can it replicate to original
>technology.

>Afterall it is obvious that SGS Thomson (STelectronics) have seen no
>market specfically for transputers, only the link technology (embedded
>in ST20s). Further as the patents holders they are no doubt going to
>want to control and profit from, but not fund any new or replicative
>transputer innovation.

>So when can I legally start producing my 100% compatible opencore
>transputer?

I looked this up a while back. Most of the patents were issued in about
1981-87, with one or two more in the early 90s. Since I think patents
can only be extended up to 20 years, I would have thought that all the
patents on the original transputer (T2xx, 4xx, 8xx) have probably
expired. There may be some more patents from the T9000 which haven't
expired.



 
 
 

Transputer patents, licences and copyrights

Post by john jaks » Thu, 15 Apr 2004 08:14:55



> So when can I legally start producing my 100% compatible opencore
> transputer?

> Nme. God Bless.

Why on earth would you want to create a 100% compatible. If you have
access to a cheap fab, maybe some reason if you must have plug
compatible and sockets to fill. Otherwise you will have to use FPGA
which is not a good platform for cloning old comp archs but is a good
platform for creating new FPGA friendly cpus.

Anyway you can create a cpu that is essentially a Transputer but
incompatible as long as it runs Occam and similar languages. FPGAs are
an order of magnitude faster now than the old 1u cmos and also 1 or 2
orders easier to do design since you don't have to design memory
arrays, fast adders etc, those are all ready to assemble.

I'd recommend starting with a RISC core with registers in memory
ofcourse. When that works you can layer the extra messaging stuff on
top.

I am using a barrel engine for my design, but its still a little way
from running code stand alone, although most of the blocks are in
debug and should come together soon. Then I have to design cache,
links etc.

Still hoping for 250MHz after PAR for Virtex2 pro and alot less from
anything else.

regards

johnjakson_usa_com

 
 
 

Transputer patents, licences and copyrights

Post by Andy Rabagliat » Thu, 15 Apr 2004 19:07:51




> > So when can I legally start producing my 100% compatible opencore
> > transputer?

> > Nme. God Bless.

> Anyway you can create a cpu that is essentially a Transputer but
> incompatible as long as it runs Occam and similar languages.

There were some important patents Inmos held regarding internal
links being treated the same as external, the linked list process
queues, and the use of negative workspace to hold process state
information.

I think the scheduler stuff, like waiting process pointers being
kept in Channel words, that were also there.

Even if your transputer is not 100% compatible, you will be hard put
to work around those issues.

Cheers,    Andy!

--
http://wizzy.org.za/

 
 
 

Transputer patents, licences and copyrights

Post by john jaks » Thu, 15 Apr 2004 23:33:52





> > > So when can I legally start producing my 100% compatible opencore
> > > transputer?

> > > Nme. God Bless.

> > Anyway you can create a cpu that is essentially a Transputer but
> > incompatible as long as it runs Occam and similar languages.

> There were some important patents Inmos held regarding internal
> links being treated the same as external, the linked list process
> queues, and the use of negative workspace to hold process state
> information.

> I think the scheduler stuff, like waiting process pointers being
> kept in Channel words, that were also there.

> Even if your transputer is not 100% compatible, you will be hard put
> to work around those issues.

> Cheers,    Andy!

Perhaps, what about KROC, any SW implementation of Occam on base cpu
must have the same issues.

I can understand the ARM cloning issue, its still alive and people
(students) still want to direct copy it, but this is pretty much the
reverse.

Since I am not privy to any details other than those described in
Occam texts (Burns etc) I think I am on safe ground. Besides the
innermost process model I am using is more generalized than Transputer
model to support HW simulation, ie many process priorities, and much
of that will be in SW with HW help to make it perform well. Most of
what I am doing is well known in the literature, just a question of
bringing multiple concepts together in a new way. I try not to invent
anything if possible. I believe the FPGA companies have a patent
umbrella that protects their customers from patent suits from ASIC
companies that are at the circuit low level.

The -ve wp idea for hiding P state is pretty darn obvious, like hiding
cookies behind a false wall. Still I will have to refer to alot of
common texts to make sure I am not inventing.

So do you think ST will come after me after doing what they did with
the it.

regards

johnjakson_usa_com

 
 
 

Transputer patents, licences and copyrights

Post by Nm » Fri, 16 Apr 2004 02:10:06




> > So when can I legally start producing my 100% compatible opencore
> > transputer?

> > Nme. God Bless.

> Why on earth would you want to create a 100% compatible. If you have
> access to a cheap fab, maybe some reason if you must have plug
> compatible and sockets to fill. Otherwise you will have to use FPGA
> which is not a good platform for cloning old comp archs but is a good
> platform for creating new FPGA friendly cpus.

Fair point. The task for myself is 100% software, machine code and
driver compatibility. The electronics will be 100% compatible at the
tram level.

I felt duplicating the original architecture would be a good first
step; albeit a very big step. Building a new FPGA 'friendly' risc cpu
with 100% transputer code compatibility was step two. Optimization
will occur later.

Nme. God Bless.

 
 
 

Transputer patents, licences and copyrights

Post by f.. » Fri, 16 Apr 2004 02:39:29



Quote:

> Perhaps, what about KROC, any SW implementation of Occam on base cpu
> must have the same issues.

UKC was "given" the occam-compiler, and other, sources by Inmos/
SGS-Thompson, as it was then.  We were given permission to do pretty
much what we liked with the software, including releasing it as
open-source, with the condition that the software was _not_ used to
generate code for Transputer hardware.  The version of the occam
compiler in KRoC generates code for a "virtual transputer", that is
a sort of T800 hybrid.

I'll steer clear of the hardware issues, but there is plenty of
literature describing -ve workspace offets, etc.  iirc the
instruction-encoding used by the Transputer was also patented.
As far as KRoC goes, it probably wouldn't be too hard to shove
the process state into +ve workspace slots.  At a guess, the
patents regarding -ve workspace-offsets, link technology, etc.
are probably hardware-specific.  I can't be sure about this, however.

--
Fred

 
 
 

Transputer patents, licences and copyrights

Post by Andy Rabagliat » Fri, 16 Apr 2004 16:44:00



Quote:

> The -ve wp idea for hiding P state is pretty darn obvious, like hiding
> cookies behind a false wall. Still I will have to refer to alot of
> common texts to make sure I am not inventing.

> So do you think ST will come after me after doing what they did with
> the it.

Depends how much money you have :-)

I doubt it. I certainly won't report you, except to comp.sys.transputer :-)

Quote:> The -ve wp idea for hiding P state is pretty darn obvious

It may be obvious now - but I am sure it is patented. I cannot think
of any other sensible way to do it, so you should just use it.

I think the PDP8 used to store the return-from-subroutine address just
before the subroutine itself - branch-and-link - so no recursion.
We think that is pretty dumb now, because someone invented the stack.

I am interested in your project - I think the Transputer still has a
lot to teach the computer science community.

Cheers,     Andy!

 
 
 

Transputer patents, licences and copyrights

Post by john jaks » Fri, 16 Apr 2004 23:50:54




> > The -ve wp idea for hiding P state is pretty darn obvious, like hiding
> > cookies behind a false wall. Still I will have to refer to alot of
> > common texts to make sure I am not inventing.

> > So do you think ST will come after me after doing what they did with
> > the it.

> Depends how much money you have :-)

Hi Andy

Not being a semi comp with money helps. If there was serious patent
resistance to anything I would just dump the project into gpl and wait
for acceptance. I have a patent myself from last job that would take
an hr to explain to somebody with advanced EE math, now thats a real
patent. Most patents I come across are alot more trivial.

Quote:> I doubt it. I certainly won't report you, except to comp.sys.transputer :-)

Already reported myself to this NG and more often c.a & c.a.fpga
depending on story. I post there more often since there are more
readers.

Quote:> > The -ve wp idea for hiding P state is pretty darn obvious

> It may be obvious now - but I am sure it is patented. I cannot think
> of any other sensible way to do it, so you should just use it.

> I think the PDP8 used to store the return-from-subroutine address just
> before the subroutine itself - branch-and-link - so no recursion.
> We think that is pretty dumb now, because someone invented the stack.

Good job as an oldy I have alot of really OLD cpu books, I remember
PDP8 quite well. Its gets harder to understand 60s oldspeak though as
time goes on.

I may just use 0 & 4|8 offsets instead, ie all general wp start at
4|8, the literals are still 0,1.. but the HW knows when to add 4|8.
There is always a slight simplication if addition doesn't go -ve for
HW design purposes even though they are equiv. The choice of 4 or 8 is
due to P structure just fitting 1 cache line.

The whole link list subject is also a nonpoint. Turns out I already
built the same data structure for a hierarchical layout editor 20yrs
ago after I left Inmos. A hierarchy of P is same as a hierarchy of HW
cells, only differences is that Ps create their child cells/Ps as
program runs instead of a mask designer. The Ps also have 1 more link
into a P event queue. This is also old news to HW simulation. Also P
lists must be double linked on the event queue side for rapid
swapping. The others can be single or double since Ps new/del less
often than swap.

Quote:> I am interested in your project - I think the Transputer still has a
> lot to teach the computer science community.

> Cheers,     Andy!

Ofcourse I do too, I am pushing the idea that FPGAs are in fact
Transputer cousins at a much finer level of granularity, tiny PEs
connected with HW wires pt to pt rather than channels. No wonder so
many papers on Occam->FPGA and HandelC etc. Occam internals are not
far from HDL event simulation. Verilog includes Occam like events but
no Alt. I am fighting the HW isn't SW argument all the time, well if
can be expressed mathematically, HW is the same as SW (more or less).
This cpu is modelled in both C RTL & Verilog using a common source
with C adjustment to Verilog master code.

I hope that interest turns in to SW/HW development for many. You will
need to buy some FPGA dev boards but thats a little way off. Perhaps
you feel like doing some TRAMs with FPGA+RLDRAM as a start. I saw your
bio at inmos, I left before you came.

On the compiler front I had been working on lcc 1st, I have rewritten
the 1st half to include a preprocessor,lexer,parser for a combined
Verilog/C/Occam language. I was just about to go into C sematic type
checking (yuck) when I thought it might be an idea to actually have
some HW to compile for, hence the rather rapid development since Feb
04. FPGAs are like that.

If U.Kent or anybody wants to write a compiler, they are most welcome
to enquire about ISA.

The cpu is right on the edge of running unrelated 16 threads for some
toy apps. The par/alt stuff is well off in the future though (months).

regards

johnjakson_usa_com

(yahoo for the spambots)

 
 
 

Transputer patents, licences and copyrights

Post by Alec Cawle » Sat, 17 Apr 2004 02:20:26




Quote:>I think the PDP8 used to store the return-from-subroutine address just
>before the subroutine itself - branch-and-link - so no recursion.
>We think that is pretty dumb now, because someone invented the stack.

So did the Elliot 903. So, I think, did the DG Nova and the HP1000
families. The stack wasn't entirely intuitive.

Mind you, the stack may give way to the heap if we get really good heap
handling.


 
 
 

Transputer patents, licences and copyrights

Post by john jaks » Sat, 17 Apr 2004 08:34:00





> >I think the PDP8 used to store the return-from-subroutine address just
> >before the subroutine itself - branch-and-link - so no recursion.
> >We think that is pretty dumb now, because someone invented the stack.

> So did the Elliot 903. So, I think, did the DG Nova and the HP1000
> families. The stack wasn't entirely intuitive.

> Mind you, the stack may give way to the heap if we get really good heap
> handling.

The stack is dead, long live the heap!

In this cpu there is no stack, it serves no purpose. Since all func
calls are treated the same way as new process, the mechanism is
common. The difference lies in the 1st few opcodes, New_func fills in
new wp[-ve] with return ip & parent wp etc and continues. New_process
fills in wp[-ve] with various links and returns leaving new process in
queue. New_store simply returns ptr to store.

There are also no func calls, only cc branches which take 0 cycles
(though some micro penalties are present WRT instruction queue). The
location just left is known to be good for a few cycles to certain ops
like New,Ld which can stash it away before another bra occurs.

That means New must be very eficient and light, since its 1 of the
most important cpu features, it must be fast & common for New_store,
New_func & New_process. It also means there is some role for SW GC. In
the event that heap lists must be traversed, there needs to be support
for rapid ptr walking in 1 or 2 effective cycles, as well as light
funcs or xops as they were once called (funcs with no private store).

In the HW compiled model the process creation is basically 1 bulk New
for many tiny procs which live the same lifetime ie 1 big arena.

For func calling, parameters are computed in the calling body into a
pool and a ptr passed to the called func in a defualt reg maybe wp1.
wp0 follows usual RISC convention of taking any result but returning
0.

One could argue to keep the stack for faster lighter func frames, but
that detracts from the par body of work and adds its own list of
problems. Better to kill it and sort out the heap issues.

This is somewhat early to be describing this but its seems the stack
must go.

regards

johnjakson_usa_com

 
 
 

Transputer patents, licences and copyrights

Post by John » Wed, 21 Apr 2004 10:08:44





> > > So when can I legally start producing my 100% compatible opencore
> > > transputer?

> > Why on earth would you want to create a 100% compatible. If you have
> > access to a cheap fab, maybe some reason if you must have plug
> > compatible and sockets to fill. Otherwise you will have to use FPGA
> > which is not a good platform for cloning old comp archs but is a good
> > platform for creating new FPGA friendly cpus.

> Fair point. The task for myself is 100% software, machine code and
> driver compatibility. The electronics will be 100% compatible at the
> tram level.

> I felt duplicating the original architecture would be a good first
> step; albeit a very big step. Building a new FPGA 'friendly' risc cpu
> with 100% transputer code compatibility was step two. Optimization
> will occur later.

I think that duplicating the original architecture would be fantastic.
Just "because it would be"... Even if it didn't quite make it 100%
coverage for quite a while. We are not in this for raw compute speed
are we? Why would we want the original arch on an FPGA in this case?

If speed, then Occam->VHDL compilers seems appealing. Perhaps a
PowerPC core (done already) and SPOC (Occam to C), with Occam->VHDL
for speed critical bits.

Step 2, 100% machine code, software and driver compatibility would be
very useful. How about a dead simple micro engine, that drives a t414
h/w interface, with event, reset, analyse, possible hardware assist
for prefix instruction decode and little else? An initial performance
goal of 1 T414 MIP. The idea being a small CPU core that inserts wait
states when it can't keep up (most of the time). Would be good for
students to learn hands on about microcoding.

If the core was small enough, perhaps 4 could fit on one FPGA. Sharing
the microstore to save space? [I don't know much about FPGAs if that
is not evident already... 8-)]

Any form of compatible transputer core would be a bonus for home
electronics projects, simple control, etc. I would be very happy if it
was just compact and clocked at a handy 5mhz...

Once a s/w compatible core is done, it may spur more people to dust
off their old software and put more Occam/transputer apps online for
all to play with...

As an aside, I wonder what happened to the old Inmos CAD system? Did
ST port the designs to some other system, or did they use the Inmos
CAD system to design the T805?

Anyone know what the T9000 was designed on?

 
 
 

Transputer patents, licences and copyrights

Post by john jaks » Wed, 21 Apr 2004 23:25:40






> > > > So when can I legally start producing my 100% compatible opencore
> > > > transputer?

> > > Why on earth would you want to create a 100% compatible. If you have
> > > access to a cheap fab, maybe some reason if you must have plug
> > > compatible and sockets to fill. Otherwise you will have to use FPGA
> > > which is not a good platform for cloning old comp archs but is a good
> > > platform for creating new FPGA friendly cpus.

> > Fair point. The task for myself is 100% software, machine code and
> > driver compatibility. The electronics will be 100% compatible at the
> > tram level.

> > I felt duplicating the original architecture would be a good first
> > step; albeit a very big step. Building a new FPGA 'friendly' risc cpu
> > with 100% transputer code compatibility was step two. Optimization
> > will occur later.

> I think that duplicating the original architecture would be fantastic.
> Just "because it would be"... Even if it didn't quite make it 100%
> coverage for quite a while. We are not in this for raw compute speed
> are we? Why would we want the original arch on an FPGA in this case?

Fantastic it would be (in a crazy way) :-).

Quote:> If speed, then Occam->VHDL compilers seems appealing. Perhaps a
> PowerPC core (done already) and SPOC (Occam to C), with Occam->VHDL
> for speed critical bits.

vertex2Pro includes 2 or 4 PPC cores. Thats the only way a poor user
can get their hands on such things. Actually not very cheap either.
Given IBM story of selling lowend PPC off to AMCC, I am not so sure
about that anymore. It doesn't have FPU either.

Quote:> Step 2, 100% machine code, software and driver compatibility would be
> very useful. How about a dead simple micro engine, that drives a t414
> h/w interface, with event, reset, analyse, possible hardware assist
> for prefix instruction decode and little else? An initial performance
> goal of 1 T414 MIP. The idea being a small CPU core that inserts wait
> states when it can't keep up (most of the time). Would be good for
> students to learn hands on about microcoding.

> If the core was small enough, perhaps 4 could fit on one FPGA. Sharing
> the microstore to save space? [I don't know much about FPGAs if that
> is not evident already... 8-)]

A true TP clone would likely be several times bigger & slower than a
modern design. Getting 4 into a FPGA would be difficult & expensive.
The real issue is to exploit the FPGA resources that are available ie
the amazing bandwidth available to all those BlockRams. The area req
for even a simple cpu means you have access to about 4 independant
true dual ported Block rams of any binary shape between 512.32 to
16k.1. For best performance you go as wide as possible and keep the
rams working independantly to do upto 8 mem access per cycle. Now
thats quite hard to organize.

If I wasn't doing this in FPGA, I would need a budget of maybe $5m to
$20m to do a credible full custom VLSI design with maybe 5-10 EEs
working on project. Such a budget is never likely to be available for
redoing any old cpu period.

For an FPGA, my budget is basically time & free tools (WebPack), so
far I have spent only 3months and am pretty close to running code (not
TP code). Modelling is in C (Verilog cycle RTL style) and Verilog.
VHDL could as easily be used.

A 150MHz max for Spartan3 might give a core that fits in smallest
sp3-50 part that might sell for a few $, maybe $4 in 250Ks. A higher
performance virtex2pro could go 250MHz max, but it costs way more but
also has lots of extra technology feutures not used like Rocket Serdes
IO in the GHz region.

Quote:> Any form of compatible transputer core would be a bonus for home
> electronics projects, simple control, etc. I would be very happy if it
> was just compact and clocked at a handy 5mhz...

Certainly any fast cpu can run fine slower. A version in the older
Spartan2 might be 50MHz to 100MHz with far less cache. Extrnal clock
might be a few x slower than internal so 5MHz clock might be doable. I
am not sure about the DLL/PLL facilities yet.

Still don't see req for code compatibility.

When you can have a new cpu that is essentially a Transputer that can
run modern Occam & other C langs, then you have that route to run old
code.

There are details of the old Transputer that are not good and should
not be preserved, huffman encoding is one of them, it kills
performance and complicates design no end, its very bad on 86, nobody
else uses it at byte level anymore. The stack for local exprn
evaluation is also not good, today, conventional reg style
architectures can do several times more work per cycle, just as long
as the reg file is in memory and is wp based.

Quote:> Once a s/w compatible core is done, it may spur more people to dust
> off their old software and put more Occam/transputer apps online for
> all to play with...

Hope so.

Quote:> As an aside, I wonder what happened to the old Inmos CAD system? Did
> ST port the designs to some other system, or did they use the Inmos
> CAD system to design the T805?

> Anyone know what the T9000 was designed on?

As the very 1st person to use FatFreddy and a regular user of the HDL
simulator, I don't think they made it very far after the 1st TPs
shipped. It became obvious that proprietary tools no matter how good
can hold you back. By 89 Inmos was using more commercial tools,
Verilog and so on, I expect (but don't know) that the T9000 was done
on mostly commercial SW. FatFreddy might have been used for cells.
Even in the earliest days, a Calma was available in the office, but
its per seat cost was high v 68k worksations thats were built for
every user.

regards

johnjakson_usa_com

 
 
 

Transputer patents, licences and copyrights

Post by Steve Maudsle » Fri, 23 Apr 2004 21:46:09





> > > The -ve wp idea for hiding P state is pretty darn obvious, like hiding
> > > cookies behind a false wall. Still I will have to refer to alot of
> > > common texts to make sure I am not inventing.

> > > So do you think ST will come after me after doing what they did with
> > > the it.

> > Depends how much money you have :-)

> Hi Andy

> Not being a semi comp with money helps. If there was serious patent
> resistance to anything I would just dump the project into gpl and wait
> for acceptance. I have a patent myself from last job that would take
> an hr to explain to somebody with advanced EE math, now thats a real
> patent. Most patents I come across are alot more trivial.

I beg to differ - the test of a real patent is "is it novel, innovative and
does it make/protect money" in the style of the original patents granted by
royalty from the (?) 1600s or a bit earlier. The one that is always quoted
as "best practise" is the one for the sewing machine which is a one liner
something like "sewing with a needle with a hole in the sharp end" which
AFAIK comprehensively covered the early sewing machines until it's expiry.

Stephen

 
 
 

1. Ant Attack Patent

From the Ant Attack title screen:

"SOFT SOLID 3-D Pat.Pending"

Was any such patent every granted, and if so, what was its scope?

Phil

--

 | http://www.geocities.com/SiliconValley/Park/5427/spectrum.htm |
 | New? Read the FAQ: http://www.jetman.demon.co.uk/speccy/faq/  |
 \    Looking for something?: http://drson.vse.cz/snapsearch/    /

2. newbie questions

3. Sinclair Patent

4. ipmasqadm not working as expected

5. Big Oh of new patented sorting algorithm is O(n^2)

6. Basic Java Questions

7. Patent Protections Threatened

8. Job Opening - Software Engineer

9. MS-DOS 6 patent suit: Call for prior art.

10. Patent Protections Threatened

11. OT: SCO Cancels IBM's Unix Licenses...

12. New licenses? (was Re: An observation)