I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA.
Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.
It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.
Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.
ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.
Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
It's easier to directly generate binary object code than assembly. It also makes for a way, way faster compiler. Also, one of the first programs I wrote when developing my compiler was an object file disassembler.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
That was one example among many others that I could have chosen from compiled languages, I just happened to chose the very first successful one.
I might also add that I was surprised that you lost an opportunity to advocate for D, which what I was actually hitting for with that remark alongside a smiley.
Some people forget not only is Fortran one of the few languages with first class support for GPU programming, and one of the reasons OpenCL lost, it has all the goodies of modern languages.
I used it as example, as I could have used any other compiled language, including D.
But when Turbo C with assembler (TASM) came out those were just great. And by that asm output generating feature it was often way faster way to write something first in C, translate to asm and go from there do what you wanted with that asm directly. I'm not sure which higher level compilers came with that feature, but once available it was many times just great thing to have for sure.
Comments
I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA.
Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.
The easy way to write assembler for a machine with no compilers is to write the code in C, get the algorithm right, then translate it to asm.
I agree. Not sure whether that was the case for MS-DOS but I’m sure it was useful.
Gotta find some time to read some of the code to chill.
Or any other compiled language for that matter. :)
It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
As did many other compiled languages including those predating C, people should stop putting it on pedestal.
Fortran 77 manual for UNIX, https://www.unix.com/man_page/v7/1/f77
You can find plenty of other examples, when doing digital archaeology.
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.
Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.
ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.
It's easier to directly generate binary object code than assembly. It also makes for a way, way faster compiler. Also, one of the first programs I wrote when developing my compiler was an object file disassembler.
Yes there were alternatives.
What irks me is this mystical selling point, have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
As you point out, people are not curious enough for what is outside of their bubble and take the marketing message as is.
Even more so, when knowledge was spread via the local library and what magazines one could get their hands on.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
So by that I'm wishing you a nice day, cheers.
Fortran is a terrible language for developing an OS. It doesn't even have pointers.
That was one example among many others that I could have chosen from compiled languages, I just happened to chose the very first successful one.
I might also add that I was surprised that you lost an opportunity to advocate for D, which what I was actually hitting for with that remark alongside a smiley.
The standard language has had both dumb and smart pointers for 36 years. Based storage has been available as a common extension for over forty.
Some people forget not only is Fortran one of the few languages with first class support for GPU programming, and one of the reasons OpenCL lost, it has all the goodies of modern languages.
I used it as example, as I could have used any other compiled language, including D.
Turbo C didn't exist when MSDOS was written. Or any compiler for the x86.
Yes, you are correct.
But when Turbo C with assembler (TASM) came out those were just great. And by that asm output generating feature it was often way faster way to write something first in C, translate to asm and go from there do what you wanted with that asm directly. I'm not sure which higher level compilers came with that feature, but once available it was many times just great thing to have for sure.