Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I found an example ages ago on this but I was wondering if someone could refresh my memory. I understand its not the greatest idea to use C whilst in real mode because of your 1 MB limitation but just for the record does anybody know how to mix C and 16 bit asm for GCC?
Please no messages like your not ready for OS dev I have been getting that a lot and believe I am ready for OS dev in fact I have already started making an OS and its coming along well. And besides forums exist to discuss topics.
So if anyone knows how to mix C and 16 bit asm a link or an example would be great
Every 16-bit C compiler that I ever worked with allowed use of the SMALL (edit - my mistake, I meant TINY) memory model, which is a flat address space albeit only 64K. This is quite enough to write an OS. Minix is one example of a 16-bit mixed OS written in a mixture of C and assembler. If you are dealing exclusively with real mode then you may find a combination of Turbo-C and Tasm to be the ideal development environment. If the 16-bit code is just there to load protected mode then it may be easier to just use assembler for that part of the code.
iansjack wrote:If you are dealing exclusively with real mode then you may find a combination of Turbo-C and Tasm to be the ideal development environment.
The tiny memory model produces .COM files which were org'd at 100h, and that was their entry point. COM files have no header (they were flat binary), so there is nothing to tell a linker about that. MS-DOS device drivers were org'd at 0, but were invariably written in assembly language.
I'm not sure what point you are trying to make here. Are you saying that you can't use a mixture of Tasm and Turbo-C to write an OS? If you than I can say, from experience, that you are mistaken. I used exactly that combination to implement Minix from the source code.
If it's good enough to produce Minix then I'd say that it is probably a good enough combination for any home-brewed 16-bit OS.
I am saying you can't use it [turbo-c] to write a loader for a protected mode operating system.
Yes, it is self-evident that you cannot use a 16-bit only assembler/compiler to load a 32-bit OS
The loader runs in 16-bits, and protected mode even existed before 32-bits, so yes you can write a loader for a 32-bit OS in Turbo C - even without DBing opcodes all the way to the jump to 32-bit country, if you are aware of the old ways (and Tasm doesn't happen to miss some essential 286 privileged instructions somewhere).
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
I'm not quite sure that I see how the 16-bit Tasm supplied with 16-bit Turbo C could produce the necessary instructions to get into protected mode (other than by inserting the instructions as data), but I'll take your word for it. As I understand it those tools were purely 8086 tools.
It's a bit of a pointless discussion as I understand the OP to be asking about 16-bit code, not protected mode.
As I understand it those tools were purely 8086 tools.
wikipedia wrote:Initially released as an MS-DOS compiler, 3.0 supported C++ templates, Borland's inline assembler, and generation of MS-DOS mode executables for both 8086 real-mode & 286-protected (as well as the Intel 80186.)
The same rules apply for running a hosted compiler for OS development as it does for hosted GCCs anywhere. My turbo C was pretty much defunct before I honestly started OS development, so I haven't sorted out all the pitfalls with it, but the obvious approach would be to write a bootsector for TASM, then have it load a system-call-free tiny model app that does the rest of the executionwork, then convert it to a .COM file or have the bootloader do some MZ magic.
Last edited by Combuster on Sat Jul 27, 2013 2:12 pm, edited 1 time in total.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Is deliberately using an older version just as relevant? In the end it's just the same product with some more features.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
I was specifically was talking about Turbo C, not Turbo C++ ; they are totally different products. (Apart from anything else, one was a C compiler, the other a C++ compiler.) And Casm's original remark was about 16-bit DOS compilers. I still don't see the relevance of a 32-bit C++ compiler to a discussion about 16-bit compilers.
Of course a 32-bit compiler can produce 32-bit code. Now let's not pursue this rather silly and futile discussion any further.
Both are 16 bit, neither can do 32 bits, and both have C compilers. The only real difference is that the old one is exclusively C and one being able to do both C and C++ with all the syntax differences in effect. Your argument is just as nonsense as saying that the gnu compiler collection is not a C compiler because of g++.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
