iserver on New Platforms: OSF1 on DEC AXP
The Problem
As already mentioned [link], the Inmos implementation of the iserver protocol does not take into conderation the possibility of file handles longer than 32bits. This causes problems when the host machine is a 64-bit architecture (and FILE* pointers are 64-bits long). Here is what happens when the fopen() command is sent:
The iserver executing on a 64-bit machine receives the SP_OPEN tag from the transputer, and allocates a FILE structure. The passes the pointer to this structure (the filehandle) back to the transputer. Unfortunately, only the lower 32 bits of this filehandle are sent, since the protocol does not have room for all 64:
When the client later needs to access this file, it passes the truncated filehandle to the server, which uses it to attempt to reference the FILE structure. Unfortunately, if the FILE* pointer originally contained something in the upper four bytes, the truncated version will point to an incorrect area in memory, and the server will be unable to access the file.
There are at least three solutions to this problem; they are presented here in increasing order of "correctness":
solution #1: the "quick hack" 
This method is not guaranteed to work in all cases, but yields quick results. It is based on the idea that the top four bytes of the FILE* pointer should be constant, as long as the operating system places all streams in the same area of memory:
- look at stdio.h and note the FILE* values for stdin, stdout and stderr. If the top 4 bytes of each are not equivalent, this method won't work.
- A 64-bit filehandle may be reconstructed by prepending the top 4 bytes (found in the above step) to an incoming 32-bit filehandle.
Unfortunately, this method is not very elegant, since it prepends a constant, which may change depending on the machine running the iserver (some implementations of stdio may use a completely different method of allocating FILE* pointers, which would be incompatible with this fix).
solution #2: the
practical way
If the DEC "cc" compiler is being used, the "-taso" switch will force the linker to load code into the lower 32-bit-addressable virtual address range [ref: cc manpage]. This will effectively make the top four bytes of a filehandle zero (since they are not used to address this area of memory); nothing will be lost when they are truncated during a client-server transaction.
This solution does not require any modification to the iserver code (apart from the other standard modifications, such as changing the definitions of "long int"). The minor restriction of using only the "lower" 4GB of virtual memory is not an issue at present; if it ever did become one, the final solution could be implemented...
solution #3: the "Right Way" 
This is how iserver should have originally implemented things. The 32-bit "filehandle" passed between client and server is actually an opaque token, used by the server to index into a table of n-bit filehandles (where n is the width of a filehandle on that particular architecture). This method adds a level of indirection and isolates the protocol from implementation-specific details which caused problems in the first place.