Yes infact it is possibly..
I was experimenting in C and Assembly and I compiled a hello world in assembly 16 bit and then I studied the hex of the .com with an hex editor. Then made a small compiler in C that had only some minor functions "my own printf()", "getchar()" and "defining a string variable" =)
But that was a long time ago but it was sure fun to play around with hex. The lower language I come to the funner it is I can tell ya.
BTW it is not pointless I actually learned a lot from this when I was a complete noob. =)
Programming in raw hex - possible?
20 years ago, I was given a job. I had to take an old AppleIIe, and an optical card reader interfaced to it, and make them read a few hundred cards. The only language on the Apple was interpreted BASIC. Reading one card in BASIC took a couple minutes. This was unacceptable.
So, I wrote a subroutine in C. Hand compiled it to assembler. Hand compiled that into raw machine language (400 to 500 bytes, as I recall). Used BASIC to poke the subroutine into memory. Then called it to read each card. After several rounds of debugging, I got it working, and was able to max out the scanning speed of the card reader.
But as everyone says: it really is wisest to start with an HLL, like C. Hand compile, then hand optimize. It is doable. You learn a lot. It is not practical, unless you have a VERY important or very tiny app to work on.
So, I wrote a subroutine in C. Hand compiled it to assembler. Hand compiled that into raw machine language (400 to 500 bytes, as I recall). Used BASIC to poke the subroutine into memory. Then called it to read each card. After several rounds of debugging, I got it working, and was able to max out the scanning speed of the card reader.
But as everyone says: it really is wisest to start with an HLL, like C. Hand compile, then hand optimize. It is doable. You learn a lot. It is not practical, unless you have a VERY important or very tiny app to work on.