Just checked with Turbo C++ 1.01 that -mh isn't enough to make all pointer arithmetic 32-bit by default. The pointed-to type (in the pointer declaration) needs to be annotated as huge (e.g. char huge* p) for the compiler to generate a call to a 32-bit pointer add subroutine. Seems like this is different from Open Watcom's -mh. I don't think I ever compared the models in the two compilers.kerravon wrote:https://groups.google.com/g/alt.os.deve ... iXRm-aBQAJalexfru wrote:What exactly was the confusion/incorrectness?kerravon wrote:It took me an awfully long time to find out what the "huge" memory model in MSDOS actually was, and it didn't help that I got incorrect information in a public group (alt.os.development) with no correction from anyone.
I think at the time you mentioned this, I did in fact look at the code generated by Turbo C's huge memory model when a "long" was added to a pointer, and confirmed (what I thought was) your observation that the compilers didn't generate the code I wanted.
But I think it was only after an argument in comp.lang.c where I was repeating the (believed) assertion from you that I think I had rudimentally confirmed, that I decided to check Watcom (which I think I had moved on to) to prove I was right. And I was wrong. So I apologized in comp.lang.c and wrote the above. Actually I think there was a gap before I eventually tried Watcom and I apologized belatedly.
And as per the above link, I said maybe we were talking cross-purposes, as there was no reply with clarification.
The principals of my OS
Re: Huge memory model
Re: Huge memory model
Ok, thanks for confirming that:alexfru wrote:Just checked with Turbo C++ 1.01 that -mh isn't enough to make all pointer arithmetic 32-bit by default. The pointed-to type (in the pointer declaration) needs to be annotated as huge (e.g. char huge* p) for the compiler to generate a call to a 32-bit pointer add subroutine. Seems like this is different from Open Watcom's -mh. I don't think I ever compared the models in the two compilers.
1. Turbo C's huge is different from Watcom C.
2. That at the time of that message you didn't know Watcom C was doing the exact thing that I needed.
Re: The principals of my OS
Which is all blind and deafblind people ever get to "see" anyway.kerravon wrote:Isn't it reasonable to send ANSI escape codes and let a higher level sort that out, possibly with a fallback of only displaying text with no colors?Octocontrabass wrote:What about hardware that isn't VGA-compatible?flossy wrote:16 color text mode only, as that's easiest to implement and make programs for.
-
- Member
- Posts: 48
- Joined: Sat Jan 28, 2023 11:41 am
- Location: Belarus
- Contact:
Re: The principals of my OS
Alternatively, you can look at the implementation of this idea by me https://github.com/Alexey1994/BelOS/blo ... obal/api.cflossy wrote:So, I've been working on an OS, and I've restarted several times due to not having a plan. I now have a plan, and some principals that I've laid out.Other than that, I have a few other plans for the design.
- The user has as much power as the OS. if the OS is capable of doing something, the user do it.
- Keep it as minimal as possible. E.g. C compiler/linker, Assembler, text editor.
- Programs use no dependencies other than the kernel itself. Make everything self contained enough to run on any system running the OS.
If any of y'all are interested in helping out, let me know
- Users write their own programs and utilities for the large part, and any non-user made program can be rewritten, replaced, or modified and recompiled.
- 16 color text mode only, as that's easiest to implement and make programs for.
Here is the api provided to the program by the kernel.
But I recently added graphics to run NES emulator from another developer.
Re: The principals of my OS
Thompson didn't write the compiler. He modified the BCPL interpreter to have a syntax he liked, he and his colleagues realized they wanted more than one type and compilation would be nice, then Dennis Ritchie wrote the C compiler. I don't know how this sequence of events relates with writing the initial, assembly-language version of Unix, but I'm pretty sure they started writing Unix in 1969 and weren't finished until some point in 1970.iansjack wrote:Compilers, assemblers, and text editors already exist and can be ported to a new OS with little real effort. As for the OS described, it took Thompson about a month to write a more powerful OS than described here, complete with assembler and text editor.
Three decades seems a little long for such a simple system.
@kerravon: I think your full C90 support makes your C standard library much more complex than the original C of 1970 or so. I'm sure it's much easier to make a simple C without worrying about compatibility. And there's the question of how much energy different devs have for coding after the other activities in their life. Someone who codes for a living might take 10 years to get their OS into a good state even when using gcc and glibc, (we used to quote that figure all the time,) but once, some guy holed up in a cabin in the woods with nothing but laptops for company produced a GUI OS in 5 months.
As for the compiler, I'm told recursive descent parsers are very easy to write. I wouldn't know. I'm going for Forth because many people have done exactly what @flossy would like to, but with Forth instead of C. It's supposed to be relatively easy to make a Forth compiler, but my brain keeps getting tripped up over the indirection in the one tutorial I've looked at -- JonesForth. I'm looking at hForth now; small, simple, designed for embedded work and public domain. Lots of Forths are public domain. Perhaps that's because it had a very different niche to C.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
-
- Member
- Posts: 48
- Joined: Sat Jan 28, 2023 11:41 am
- Location: Belarus
- Contact:
Re: The principals of my OS
The recursive descent parser is really easy to make, here are some examples of my codeeekee wrote: As for the compiler, I'm told recursive descent parsers are very easy to write. I wouldn't know. I'm going for Forth because many people have done exactly what @flossy would like to, but with Forth instead of C. It's supposed to be relatively easy to make a Forth compiler, but my brain keeps getting tripped up over the indirection in the one tutorial I've looked at -- JonesForth. I'm looking at hForth now; small, simple, designed for embedded work and public domain. Lots of Forths are public domain. Perhaps that's because it had a very different niche to C.
https://github.com/Alexey1994/system-la ... ser.c#L713
and Lua
https://github.com/lua/lua/blob/master/lparser.c#L1845