OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Mar 18, 2024 10:13 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Huge memory model
PostPosted: Thu Dec 15, 2022 12:14 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
kerravon wrote:
alexfru wrote:
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.


What exactly was the confusion/incorrectness?


https://groups.google.com/g/alt.os.deve ... iXRm-aBQAJ

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.


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.


Top
 Profile  
 
 Post subject: Re: Huge memory model
PostPosted: Thu Dec 15, 2022 12:19 am 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 228
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.


Ok, thanks for confirming that:

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.


Top
 Profile  
 
 Post subject: Re: The principals of my OS
PostPosted: Thu Dec 15, 2022 12:34 am 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 228
kerravon wrote:
Octocontrabass wrote:
flossy wrote:
16 color text mode only, as that's easiest to implement and make programs for.

What about hardware that isn't VGA-compatible?

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?

Which is all blind and deafblind people ever get to "see" anyway.


Top
 Profile  
 
 Post subject: Re: The principals of my OS
PostPosted: Thu Feb 09, 2023 4:13 am 
Offline
Member
Member

Joined: Sat Jan 28, 2023 11:41 am
Posts: 31
Location: Belarus
flossy 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.
  • 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.

Other than that, I have a few other plans for the design.
  • 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.

If any of y'all are interested in helping out, let me know

Alternatively, you can look at the implementation of this idea by me https://github.com/Alexey1994/BelOS/blo ... obal/api.c

Here is the api provided to the program by the kernel.

But I recently added graphics to run NES emulator from another developer.


Top
 Profile  
 
 Post subject: Re: The principals of my OS
PostPosted: Fri Mar 17, 2023 8:00 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 811
Location: Hyperspace
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.

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.

@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


Top
 Profile  
 
 Post subject: Re: The principals of my OS
PostPosted: Sat Mar 18, 2023 12:27 am 
Offline
Member
Member

Joined: Sat Jan 28, 2023 11:41 am
Posts: 31
Location: Belarus
eekee 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.

The recursive descent parser is really easy to make, here are some examples of my code
https://github.com/Alexey1994/system-la ... ser.c#L713
and Lua
https://github.com/lua/lua/blob/master/lparser.c#L1845


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group