OSDev.org

alexfru wrote:

iansjack wrote:I probably shouldn't switch to using Smaller C as I'm afraid that it doesn't fare well with 64-bit programs.

I have yet to see a hobby OS that would put at least one full gigabyte of memory (virtual or physical) to a good use. I don't get the urge to make a hobby OS 64-bit. Is it hip? Or is it because "yes, we can"? And then there's a plethora of associated issues to solve (quirks of addressing due to 32-bit displacements in instructions, the need to implement multi-level page translation that's not sufficiently regular at all levels, no v86/BIOS, etc). Is it worth it?

I only play with OS development as a hobby because it interests me. I have no illusions that anyone is going to use the result other than myself. I find the 64-bit mode of the x86 processors more interesting, and more elegant, than the 32-bit mode (nothing to do with the amount of physical RAM supported) - in fact I started the whole business just to play around with 64-bit mode. This was very new stuff when I started out, with much less information available.

So, to me, a compiler that doesn't do 64-bit code is useless; as is one that doesn't do Arm code now that I also have a Pi to play with. So, as I said, I probably shouldn't use Smaller C. I'm sure that it's fine for those who want to do 32-bit x86 programming and are happy to use the gcc preprocessor but not the gcc compiler.

iansjack wrote:I find the 64-bit mode of the x86 processors more interesting, and more elegant, than the 32-bit mode (nothing to do with the amount of physical RAM supported)...

What's more elegant in it if we put system stuff aside? More registers? Direct accessibility of LSBs of RSI, RDI, RBP, RSP, etc?

iansjack wrote:So, to me, a compiler that doesn't do 64-bit code is useless; as is one that doesn't do Arm code now that I also have a Pi to play with.

64-bit isn't planned now. But Arm support could be added and at the basic level it shouldn't be much different from MIPS support, which is there already and you will only need an assembler and a linker.

iansjack wrote:So, as I said, I probably shouldn't use Smaller C.

That's fine. I'm not trying to sell it to you or anyone. However, I'd appreciate more users. Perhaps, someone could put together an example of how to do OS dev with Smaller C. But I'm guessing that someone will [have to] be me.

iansjack wrote:I'm sure that it's fine for those who want to do 32-bit x86 programming and are happy to use the gcc preprocessor but not the gcc compiler.

I've tried a bunch of different opensource preprocessors. There are a few usable and likely mostly correct ones, but there are a number of things I don't like about them. So, I might end up writing a preprocessor for Smaller C or reworking some of those preprocessors. It is still undecided. But eventually, there should be a reasonably good preprocessor in Smaller C (standalone or built-in). Invoking gcc for preprocessing is a temporary workaround until we get there. Compiler dev takes time just as OS dev, you know. Things are getting done and falling in place, one at a time, with some iterations. Several months ago there was no standard library. And now there's one and the compiler can be used on 3 popular platforms (OK, DOS isn't very popular anymore, but it is supported in part because it was easy to support given my familiarity with it and because it's rarely supported by new/other compilers nowadays and someone might benefit from this option).

We seem to again be drifting far from the original question into a discussion of the merits/demerits of 64-bit processing and of Smaller C. I don't think that either are relevant to the OP.

It's a shame that the poster hasn't returned. I fear that a lot of effort is being wasted on a problem that is either trivial or non-existent.