Aspex Massively Parallel co-processor (content-addressable memory)

[Luke Kenneth Casson Leighton <lkcl at samba-tng dot org>]

aspex has a SIMD processor - an unbelievable 4096 individual
_bit-serial_ processors.

its capabilities are not just vector-vector operations
(240 billion 8-bit adds per second), but also cross-vector,
for example there is a way to do a software-controlled "carry
look-ahead" across the entire 4096 processors.

[so, by storing a massively large integer number of 4096 * 32
bits in length, big-integer adds of integer length 131072 bits
can be done at a rate of one massive add per 300 nanoseconds].

the issue that aspex has is that they took a look at gcc,
and decided to leave gcc _well_alone, and to write their
own macro pre-processor that generates c-code.

this avoids any issues and problems of spending enormous
amounts of time - possibly to no gain - on a rather hairy
program :)


the c-code output is a memory-mapped access to a global
variable instance of a "struct" which contains the registers,
a bit like the amiga blitter chip, and also a bit like the
rs6000 altivec.)

i've just been talking to a couple of people at ukuug
who recommended approaches and names (thanks!) and they
recommended investigating the altivec approach, by adding
_builtin_xxxx functions (which looks like an impressive
and also unfortunately intimidatingly large amount of
work!)

as the the co-processor is a plug-in PCI card, it can be
available *regardless* of the host in which the card is
actually plugged in (as long as it runs linux of course
because the driver's only available for linux).


so, i am not entirely sure how to proceed, to get
proper support for gcc.

the issues that aspex faces are:

- the asp compiler is a macro pre-processor, which turns

 void do_parallel_op(int x_scalar)
 {
	 aop{ Aspex Assembler Instruction(Byte,0, x_scalar) }; 
 }

 into:

 void do_parallel_op(int x_scalar)
 {
    lac->pipeline1 = 0x59320800; /* 0 for byte 0, 8 for size */
    lac->pipeline2 = 0x1a932700 | x_scalar; /* scalar input */
	lac->call      = 0x0; /* tells the asp to "do" this operation */
 }

- the macro-preprocessor stage is totally independent of, and
  cannot properly interact with, gcc.

  therefore, templates are out.

  automatic register allocation, which is a 128-bit-wide
  _bit serial_ register, is out.


funnily enough, the playstation 2 with the vector co-processor
faces exactly the same programmability issues as aspex does.


i have tried a couple of hack-it-and-see approaches:

create an asp <template_args> ("Aspex Assembler Instructions")
syntax, similar to asm ("....") except with the ability to
expand template type arguments, and then:

- when a template is encountered:

	- output to a separate file {gcc_input_file_name}.tpl
	a "stub" function with asm ("#ASP_START_COMMENT_functionN")
	before, and asm ("#ASP_START_COMMENT_functionN") after
	outputted into the .tpl file, like this:

    static void fake_function1(int x_scalar)
    {

 		asm("#ASP_START_COMMENT_function1")
		 aop{ Aspex Assembler Instruction(Byte,0, x_scalar) }; 
 		asm("#ASP_END_COMMENT_function1")
	}

	- output in the CURRENT file being parsed another asm rtx
	comment asm("#ASP_REPLACE_LOCATION_function1")

	- finish the parsing, ending at the .s stage.

	- run the aspex compiler on the .tpl file, to generate
	c-code.  this generates lac->this, lac->that, with
	some "fake" functions.

	- run gcc AGAIN on the "fake" functions, terminating at
	the .s stage.

	- SPLICE the two .s files together, using the ASP_COMMENT
	parts to identify the locations!

	[yes i realise this is fraught with potential difficulties
	of which i know nothing :) ]

	- finish off by compiling from .s to .o

approach 2:

	- output to a separate file {gcc_input_file_name}_function1.tpl

	- exec off the aspex compiler, which also fires off ANOTHER
	gcc compiler on the aspex-generated .c file, which is terminated
	at the c-pre-processor stage - result: c-preprocessed code.

	- returning from the exec, temporarily switch the yacc parser
	input file from the current file handle to the just-auto-generated
	c-pre-processed file (!!!).

	- read in the tokens from the 2nd file, returning only to the
	original file when EOF on the 2nd file is reached.


both approaches sound pretty xxxxing horrible?  well, it's because
they are :) :) :)

temporary limitations of both approaches

	- i have no clue as to how to turn the gen_rtx() instruction
	expression list nor the template list of the new "asp"
	instruction into a c-code function call.
	
	i've been examining the debug output (this is gcc 2.95.2,
	i've just today downloaded latest cvs so will get up-to-date
	rapidly) functions which could possibly help.

	unfortunately, because they (in 2.95.2) are used by gcc
	for debug output, they print the _entire_ fully-template-qualified
	type of the variable, which obviously doesn't compile as
	c-code :)

	help!

disadvantages of approach 1:

	- patching together assembly files is risky.  i know that
	it should be possible to set up the assembler correctly
	however i could spend a significant amount of time
	getting this wrong, only to find that the approach i take
	is totally invalid for certain architectures, uses
	registers to communicate that cannot be optimised, and
	the host processor spends more time setting up registers
	than it does calling the co-processor.

disadvantages of approach 2:

	- switching the parser to read from a second file means
	that the c-code of the second file is placed AFTER the
	location where the templated code was called, and worse
	than that, the scope of any variables in that c-code
	are of the location where the c-code was CALLED, not from
	the templated function from which it was generated.

	ARGH!

the only possible solution i can think of to this one is
to do this:
	
	- auto-generate an inline function declaration
	with the same arguments as the "asp" statement, with
	of course the templated types replaced with real types.

	- output a matching non-templated inline .tpl file
	which gets the aspex compiler called on it, to generate
	c.

	- AT THE END of the c parsing stage, call the aspex compiler,
	to generate c, and then read that c code WITHOUT terminating
	the parser.

the idea is to rely on the inline function pre-declaration
system i spotted whilst going over the code.

the plan would be to have an inline function call which hadn't
yet been encountered, such that later on when it WAS encountered
(after it had actually been created!!) it would get
substituted back "inline".

yukk :) :)

and, of course, all of this horrible-ness is to avoid doing
the _real_ job, which is integrating a massive, and proprietary,
compiler project of 10 years development work into gcc.

suggestions, anyone (polite ones :) ?

	
-- 
----------------------------------------------------------
this message is private, confidential, and is intented for
the specified recipients only.  if you received in error,
altered, deleted, modified, destroyed or interfered with
the contents of this message, in whole or in part, please
inform the sender (that's me), immediately.

if you, the recipient, reply to this message, and do not
then receive a response, please consider your reply to have
been lost or deliberately destroyed: i *always* acknowledge
personal email received.  please therefore take appropriate
action and use appropriate protocols to ensure effective
communication.

thank you.