On Thu, 6 Jan 2005, Paul Brannan wrote:
> On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:
> > >>>>> "P" == Paul Brannan <pbrannan / atdesk.com> writes:
> If it were possible to dynamically generate C functions, there would be
> no limitation, and the only way I know to get rid of the limitation is
> to dynamically generate C functions.

There's this sort of code in GridFlow (found in RAA) to detect the CPU
type (in this case, the code is for the Pentium family incl Cx6,K6,K7,K8):

#include <stdio.h>
char get_cpuid[]={
	96,49,192,15,162,139,124,36,36,137,31,
	137,87,4,137,79,8,137,71,12,97,195};
main() {
	char result[16];
	int code;
	((void(*)(char*))get_cpuid)(result);
	code = ((int*)result)[3];
	result[12]=0;
        fprintf(stderr,"cpuid: name=\"%12s\", flags=0x%08x\n",
		result,code);
	return 0;}

The current problems with this approach are:

1. Even though through daily life I am not convinced that there exist more
than four types of CPUs (Pentium/AMD, PPC, ARM, PIC), some people hint to
me that SPARC is still on respirator and that there are subcultures for
fans of Alpha and Amiga and PDP11 and such, who really want to use Ruby
;-) How many CPU types _really_ need to be supported to be considered
portable?

2. Are there any OS'es that block execution of data-segments? IIRC, the
i386-family supports such permission flags, but I don't know which OS'es
use it for real. (Linux doesn't...)

3. The above code was generated using NASM and then f.read.unpack.join.  
If done dynamically this means starting a new process. However if the
patterns to be generated are simple/focused enough, it can be done fully
within a C and/or Ruby program without essentially rewriting an assembler
from scratch...

_____________________________________________________________________
Mathieu Bouchard -=- Montr?al QC Canada -=- http://artengine.ca/matju