Pete's Log: I like reading! part 2

Entry #1147, (Coding, Hacking, & CS stuff)
(posted when I was 23 years old.)
Ok, web browsers can blow me. There are gonna a decent number of entries today. The first item here isn't something I read, but I found it amusing enough to include.

Tera MTA Progress Report
summer 1999

This was an mpeg video on a cdrom that Arun gave me. It was very fun to watch, but contained little content beyond corporate marketing talk.

must ... buy ... tera !!!


Can dataflow subsume von Neumann computing? by Nikhil and Arvind, 16th ISCA, 1989

This was an excellent paper, I wish to read it several more times. Since writing the summary that follows, I've read up a good deal more on dataflow architectures, so I now have a better understanding of what this paper is trying to do then when I first read it. But the summary below is still worth something.

This paper describes P-RISC (parallel RISC), an architectural idea for combining ideas in dataflow computing with a RISC instruction set. Dataflow provides a new (and in many ways very elegant) means for synchronization and parallelization for code. But current compiler and software technology is geared more towards traditional von Neumann architectures. By taking a traditional instruction set but adding support for some dataflow ideas, good tradeoffs are achieved.

This paper is good. This paper is relevant, especially to PIM. Much of the current PIM architecture is based on ideas found in this paper, in particular the instruction set and the idea of continuations. The large difference between PIM and P-RISC is that in P-RISC, the memory is for the most part off-chip. P-RISC calls only for a small amount of local memory for code and frame cache, whereas PIM nodes, by design and definition, have memory onboard. In P-RISC, the authors describe separate Processing Elements (PEs) and Heap Memory Elements. In PIM, the two are combined into one unit.

The two remaining significant differences between PIM and P-RISC are the vector instructions of PIM and the tighter integration of message passing into PIM (although the paper does suggest a START instruction which serves a message passing purpose).

Unfortunately, PIM Lite adopts a very broken implementation of the ideas described in this paper. The authors of this paper took great care to describe the run-time environment as trees of frames and such. However, in the PIM Lite model, user code has no means of accessing frames other than its own. The whole idea of a frame in P-RISC is that a frame serves a similar purpose to a traditional frame (or activation record) in a singlethreaded environment. So for function calls and such, a thread would write arguments into a new frame, and then execution would start in that new frame, in the same manner that a conventional program writes arguments onto a new frame on the stack and then adjusts frame and stack pointers. Frames in PIM Lite have lost this concept, and serve simply as register sets.

A good deal of thought *must* go into the execution and runtime model of PIM. This paper brings up interesting ideas and is well thought out, I think. It should be taken into consideration when thinking about the PIM runtime model.

The paper also briefly discusses the idea of a frame manager, which would be a vital part of a PIM runtime system. There is a reason that PIM Lite does not allow a continuation to access a frame other than its own. Different tasks can be running simultaneously on a PIM node. Allowing a continuation to access other frames could allow malicious or broken code to overwrite the frames of other tasks. However, completely cutting off access to other frames is too crippling. One possibility may be to implement special instructions for writing to other frames. Some bits in the target frame could indicate what continuations are permitted to write to that frame. Things to think about.