pouët.net

I think the Intercal language has something like that.

Anyway, all of this should be done by hardware.

trace_ray

that instruction was added in the haswell new instructions, coming soon to a x86 processor near you: http://software.intel.com/sites/default/files/m/f/7/c/36945
"PEXT - Parallel Bit Extract" (in chapter 7.2)

Nice. PEXT and his counterpart can be used to do morton order conversion of 2D coordinates.

Back in the days when I was writing software texture mappers for x86 I would have given away an arm for that.

re: hardware GC
http://en.wikipedia.org/wiki/Intel_i432

SSE2 integer horizontal adds. Proper ones that sum up the entire register (16x8 → 1x64, 8x16 → 1x64, or 4x32 → 1x64), not like the useless PHADD* stuff for float that nobody would ever want to use. (I mean, seriously… what's the point of such instructions if it's faster to shuffle-and-add?)

The closest you get currently seems to be either abusing the muladds, or shuffle-and-add, depending on the input size.

A set of instructions with new design of memory controller where operation could be done very efficiently in parallel on different address in memory. Maybe by splitting memory into small units and having a tiny ALU into each unit. If each 64kb of my PC would have a 6510 attach to it, for 2 gigs of RAM, I would end up with 32768 CPU.

torus: way more general than morton actually. you can do almost the whole family of patterns described here with pdep/pext. then again, you can step those directly in your interpolation too, it's not that expensive :)

xenon: Come on, that's practically just an overly specialized version of what I suggested!

There are many ways to make instruction sets nicer, a fundamental one is removing result-use stalls for condition codes. ARM has a sort of solution, but it can be improved. Other improvements remove the instruction decode stage, which means fixed 4-8 byte instructions like a few 70s supercomputers had. Usually it's enough to overlap that stage, and since memory bandwidth gets worse with longer instructions, it's not really a great idea. But it could be a nice instruction set :)

For performance, I'd say it's about time we got smart memory. Instead of changing a chunk of memory with a loop, you send its built in little ALUs 1 instruction and the address range. Could be done on the cache line level.

For CPUs with caches, I think many would drool over actual detailed control over what's in the caches. ;) Some instructions for that wouldn't hurt.

A CPU with a smart cache coupled to a bunch of stack registers could actually do without conventional registers, and only the number of bits to encode stack#+offset would set the limit to how many registers you could use in a function, and you could have symbols for the variables on the "stack" instead of fixed register numbers or cumbersome aliases. The variables could also be of varying size, making byte-juggling effortless. You'd get a massive freedom from register-management on an 8-bit "accumulator" type CPU, and of course others too.

A binomial instruction could have many uses and would remove the need for many tables. But only if it was faster than a LUT read ;)

@kusma
OK, how about:

print_real_edible_warm_pizza_out_of_the_printer

hund.

as in,

ryg, Photon: Whoa, that was informative.


but will it fetch?

in the future, we will only need photons, muons, bosons and gluons

I just thought that it would be really nice to have all the blending operations in hardware but there is couple of problems: cool ones are really ugly(in terms of complexity) and I'd rather have them on my GPU.

swizzling is nothing. none of you have yet figured that this is gonna revolutionaze intercal!

except of course pulkomandy. i could try reading the whole shit first