Re: [9fans] speaking of kenc

[Roman Shaposhnik <rvs@sun.com>]

On Sun, 2007-05-06 at 14:18 +0100, Richard Miller wrote:
> > The
> > transputer had no assembly.
> 
> Not qute true actually.
> 
> The inmos occam compiler for the transputer did have an inline
> assembly language construct.  But this quote from my copy of the
> Transputer Development System manual (1988) shows its use was not
> encouraged.  Note the implication that the machine language should
> only be of interest to compiler writers ...
> 
> "The code insertion mechanism enables the user to access the
> instruction set of the transputer directly within the framework of an
> occam program.  Symbolic access to occam variable names is supported,
> as is automatic jump sizing.  More details on the instruction set may
> be found in the INMOS document 'The transputer instruction set -- a
> compiler writer's guide'. 
> 
> "Code insertion may be employed to perform tasks not possible from
> occam, or for particularly time-critical sections of a program.  There
> are several reasons, however, which should encourage the user to
> refrain from using code insertion as a solution to problems which may,
> with some thought, be solved using occam.  Paramount among these is
> that the validity of a system consisting entirely of occam can be
> checked by the compiler.  A compiler can check usage of channels,
> access to variables, communications protocols and range violations.  A
> single code insert prevents the compiler from performing these checks
> adequately.  A second reason for not using code insertions is that the
> transputer instruction set is suited for use by a high level language,
> particularly occam, and algorithms which are simple to code and easy
> to debug in occam become difficult and obscure when coded in the
> transputer instruction set directly."

  The above sounds very appropriate. Note, that given a proper mechanism
for creating asm-based intrinsic routines and also a proper mechanism
for inlining them -- we can have a very attractive solution to the
asm problem in C language as well. From that vantage point, GNU __asm
inlines surely seem like an overkill.  

Thanks,
Roman.