You don't need a char type to implement SHA-256. You can do the padding CPU-side, it's not something the GPU can do well in the general case. But if you have a fixed input size you can do the padding GPU-side using bit masks (without needing char types, just plain ints). In practice though a general purpose implementation is always going to suck hard in terms of performance in a parallel environment - where any existing overhead is magnified hundred-fold - so you have to tune the code to your needs by optimizing parts that you know will always work the same (for instance, fixed input sizes, constant prefix/suffix, characteristics of the output hash you are looking for, all this stuff you can use to make the GPU code leaner).

Essentially, to put it bluntly: if you need a char type to implement SHA256 on the GPU, you're either not optimizing well enough, or you don't know enough about your target inputs and outputs to make efficient use of the GPU in the first place.

There are tons of both OpenCL and CUDA solutions out there. As far as I know most graphics cards support DirectX, but not OpenCL or CUDA. Also, I think, if there are compute shaders, which are meant to not only be used for graphical purposes, why didn't they add a 1 byte data type? Its pretty basic for general purpose calculations.

Sure, but how many graphics card support DX10/DX11 compute shaders and at the same time don't support some flavour of OpenCL/CUDA? Every NVIDIA card in the past three years or so has had CUDA. OpenCL has been around for around four years. DX11 is not much older than that. And if you want optimal number-crunching performance you pretty much need to use them to do all the low-level tweaks needed to get the real speed benefits. Compute shaders are not slow, but they were designed for graphics interop in mind, and are less configurable than full-blown compute languages.

So you are basically saying that in order to write optimal code, I need to know the algorithm well instead of just copying it.

And also what you intend to do with it. General purpose implementations are going to be much slower than specialized implementations, especially on a GPU.

Well, you are right. I said compute shader, because its the straight forward method. But because hlsl is the same for all shaders, its just a ctrl-c ctrl-v to convert it into a pixel shader, and run it on older devices.

I don't think compute shaders map 1:1 to pixel shaders. The language may be the same, but I don't think you have structured buffers or unordered access views or configurable work groups in DX9 pixel shaders, so it'd be like in the old days, writing GPGPU code using vertices and textures to store inputs and outputs.

What cards do you need to support? What is your goal? We can't help you choose technologies or ways to implement an algorithm if we don't know what you are looking for.

And there is an other thing I was thinking about a long time, and it might be the solution: Is it possible (even with some crazy hacking) to write DirectX shaders in assembly? Or it is just too complicated because of the different video card types.

I don't think you can do that, at least not in DX10+. Perhaps in DX9 it's possible, I'm not sure.

I don't have a big project, or anything like that, so I don't really have specifications either. I have an old laptop with an integrated graphics card, with only DX10 support. My goal is (as Necrolis mentioned) to write a bitcoin miner.

Good news! Most miners are open source so you can have a look at them. Their kernels are a bit odd however. I'm currently playing with BFGminer.