No, and generally even the binary itself doesn't expose any of that, since you want the same program to run on your in-order atom and your OoO, multithreaded, Core iFoo.
The big exceptions being SIMD and VLIW, two similar forms of explicit parallelism. They more or less require programming language support to use fully, and most older languages are purely scalar though some can be used in a manner that is fairly amenable to automatic vectorization.
At the ISA level you're right, those do require explicit instructions (or bundling of instructions). At the programming language level no.
VLIWs can be programmed by normal compilers with well understood techniques (though variable memory latency makes static scheduling hard to do well in practice for most workloads). You just throw your C code into the compiler and it will spit out valid binaries and this has worked for as long as there have been VLIW machines.
The techniques for auto-parallelizing 'for' loops by compilers into SIMD instructions are a more recent development, but they certainly exist. The Intel C Compiler is particularly good at that, but Clang and GCC can do this too.
I did mention automatic vectorization. I know it exists, but it is not perfect even in Intel's implementation. Compilers simply cannot be relied upon to always find and take advantage of opportunities for parallelism in serial code. Having language constructs that explicitly express that parallelism helps ensure that the compiler at least tries to generate parallel code, where given straight C it might just decide that the loop body is too big to bother with or that the side effects are too complicated to prove it can be parallelized.
