OSDev.org

Posted: **Wed Nov 09, 2022 10:14 am**

You watch that "Stokfish" channel on yt ?
That's where you got this quote I guess

Posted: **Wed Nov 09, 2022 10:49 am**

devc1 wrote:You watch that "Stokfish" channel on yt ?
That's where you got this quote I guess

I can't tell if you are joking or not... In any case: https://tolkiengateway.net/wiki/Ring_Ve ... dows%20lie.

Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all, and in the darkness bind them,
In the Land of Mordor where the Shadows lie.

Posted: **Wed Nov 09, 2022 12:43 pm**

Posted: **Wed Dec 07, 2022 10:57 pm**

devc1 wrote:So, in this OSDEV Community. We've got some very experienced users in os developement. Why don't we unite and make an Exceptionnal OS, with a new design ?

Mostly from scratch (the boot manager, the kernel, the library, most of the drivers, services and the apps)

Stockfish is the best because it has a large community behind it.

Sorry for seeing this late. But I'm curious why you don't think Linux already qualifies as an "exceptional OS". It has millions of lines of code worth billions of dollars if you had to actually code it. And it's available for free, and comes with source code if you want to change anything.

Is there something wrong with it that would make you want to redesign it from scratch, and are you sure your new version would really be better?

Posted: **Wed Dec 14, 2022 7:42 am**

If we are anarchists why don't we do anarchy?

We could not work on "one ultimate OS" but write libraries, functionality etc. keeping in mind that it could be reused by others.
The libutf clones by Plan 9 is a good example [url=https://github.com/cls/libutf]liburf@github[\url].

We could expand those principles to other stuff.

Posted: **Wed Dec 14, 2022 1:15 pm**

arseniuss wrote:If we are anarchists why don't we do anarchy?

We could not work on "one ultimate OS" but write libraries, functionality etc. keeping in mind that it could be reused by others.
The libutf clones by Plan 9 is a good example [url=https://github.com/cls/libutf]liburf@github[\url].

We could expand those principles to other stuff.

The above is copyrighted, so I personally won't be linking in copyrighted material into anything of mine, regardless of how many people try to convince me that the license is absolutely fantastic.

On top of that, I'm not aware of any missing library function in PDOS that I actually want.

The only thing I'm really missing is a public domain C90-compliant compiler. There are 3 being actively worked on, the most advanced being SubC, but the 50+ year quest hasn't been achieved yet.

Oh, also it's not critical, but if I want to maintain Win32 compatibility I don't think the public domain linkers I have (pdld and ld86) are capable of producing PE executables or DLLs.

Oh, and I need some public domain 68000 assembler to support setjmp, longjmp and 32-bit division etc routines generated by GCC 3.2.3.

So what that means is that the library functions required to support a basic MSDOS-like system, already exist, as public domain C code. Or, if they're not library functions, it means that PDOS is incorrectly designed, and something that should be in a library has been put into instream code.

If that is the case, if you tell me the library function you expect to exist for an MSDOS system, let me know and I'll see if I can rip it out from wherever it currently exists in PDOS and put it into a library (you'll need to tell me the library name too).

Before I do that work it would probably be best to find out if someone actually has a use for said library function in an OS that they are about to write, or an existing one that they also intend to transform to use the new osdev-standard library.

Posted: **Wed Dec 14, 2022 1:29 pm**

kerravon wrote: If that is the case, if you tell me the library function you expect to exist for an MSDOS system, let me know and I'll see if I can rip it out from wherever it currently exists in PDOS and put it into a library (you'll need to tell me the library name too).

Before I do that work it would probably be best to find out if someone actually has a use for said library function in an OS that they are about to write, or an existing one that they also intend to transform to use the new osdev-standard library.

I agree there's little sense in putting effort moving functions to a separate library, but I do find it helpful to create new libraries preemptively since it makes it easier to reuse functionality later on. IME it also helps with separating functionality and preventing "leaky abstractions" as each library has a much more limited scope than an entire project.

Posted: **Wed Dec 14, 2022 2:22 pm**

arseniuss wrote: We could not work on "one ultimate OS" but write libraries, functionality etc. keeping in mind that it could be reused by others.

We could expand those principles to other stuff.

Actually, I thought of something else. Maybe you can get the ball rolling.

I have skills in some areas but not others. I don't even know how to quantify it. But as a result, some things mostly "just happen", they're not really designed, and I don't even really know how to design them.

So here is a "library" (I guess?) that provides routines for accessing a FAT file system:

https://sourceforge.net/p/pdos/gitcode/ ... /src/fat.h

I suspect it hasn't been abstracted correctly.

I have routines that take both a FAT and a FATFILE as parameters.

I suspect that there should be a 3rd data type, as there are multiple physical disks, then each disk can have partitions, then each partition can have files.

So maybe FATFILE needs to have an internal pointer to the partition it belongs to (is there some design principle in play here?), and then the partition has a pointer to the physical disk it is associated with. I basically have this last thing already, and it's called "parm". Maybe FAT needs to be renamed to FATPART?

So maybe the object count is correct after all. Who knows.

Regardless, I added support independently of this code to open a raw disk, so I can do fopen("drv81:", "r+b");

Oh yeah, that reminds me of something else you may be able to help with. I made it so that you can go "drv81:;size=100000" so that you can limit the size of the disk that is seen. This filename string can then be used by any application. Are you happy with the use of ";"? Originally I was going to use "," but that clashes with use of comma by CVS.

But currently I don't have the ability to open a FAT partition the same way, e.g. fopen("C:", "r+b");

I haven't yet considered how to work that into the design. Oh yeah, I do have absolute disk read and write APIs (same as MSDOS). Also absolute drive read and write APIs so that you don't need to use the BIOS (you can't use the BIOS when running PDOS/386 (as opposed to PDOS/86) anyway). Are there better names to distinguish between disks and drives?

Using just "C:" is bound to end up with disks being trashed accidentally, so it probably needs to be "dskC:". Perhaps you can confirm with the portion of the OS community writing MSDOS-like OSes that they are happy with that naming standard? Or are most people wanting to use the Windows convention, whatever that is?

Posted: **Mon Jan 02, 2023 9:24 am**

kerravon wrote: 32-bit division etc routines generated by GCC 3.2.3.

Division is simple to support in any assembler language, including FPGAs using Verilog. You just rotate the quotient and compare it with the dividend and subtract from it when lower and set the appropriate bit.

Well, it will take 32 cycles, but in a FPGA it's possible to pipeline the operation so you can do one division per clock cycle.

Multiplication can be done in a similar way.

Verilog: (non-pipelined)

Code: Select all

  always @ ( posedge clk ) 
  begin
    if (start)
    begin
      mask[17] <= 1;
      mask[16:0] <= 0;
      curr[29:17] <= count;
      curr[16:0] <= 0;
      quot[16:0] <= 0;

      if (sum[42])
      begin
        sign <= 1;
        divend <= ~sum[41:12];
      end
      else
      begin
        sign <= 0;
        divend <= sum[41:12];
      end

      running <= 1;
    end
    else
    begin
      if (running)
      begin
        if (mask == 0)
        begin
          res[15] <= sign;

          if (sign)
          begin
            if (quot[0])
              res[14:0] <= ~quot[15:1];
            else
              res[14:0] <= (~quot[15:1]) + 1;
          end
          else
          begin
            if (quot[0])
              res[14:0] <= quot[15:1] + 1;
            else
              res[14:0] <= quot[15:1];
          end

          running <= 0;
        end
        else
        begin
           if (divend >= curr)
           begin
            divend <= divend - curr;
            quot <= quot | mask;
          end

          mask <= mask >> 1;
          curr <= curr >> 1;
        end
      end
    end
  end

Posted: **Mon Jan 02, 2023 8:28 pm**

rdos wrote:
kerravon wrote: 32-bit division etc routines generated by GCC 3.2.3.
Division is simple to support in any assembler language,

Hopefully someone who agrees that that is simple will provide the necessary code to replace all or part of lines 21 to 40 here:

https://sourceforge.net/p/pdos/gitcode/ ... misupa.asm

It has been a little less than 2 years with no volunteers to date.

Also it looks like it is for the VBCC compiler, not GCC. I think GCC is 68020-only, not 68000.

Posted: **Tue Jan 03, 2023 2:13 am**

Unsigned division algorithm (pseudo-code):

Code: Select all

Inputs: Divisor > 0, Dividend >= 0
Outputs: Quotient, Remainder
Temporary: Shift Count
Procedure:
  Shift Count := ilogb(Dividend) - ilogb(Divisor) #ilogb(x) = index of highest set bit, ilogb(0) = -100 or so
  Remainder := Dividend
  Quotient := 0
  if Shift Count >= 0:
    Divisor := Divisor shl Shift Count
    while Shift Count > 0 do:
      if Remainder >= Divisor:
        Remainder := Remainder - Divisor
        Quotient := Quotient or 1
      Divisor := Divisor shr 1
      Quotient := Quotient shl 1
      dec(Shift Count)
    if Remainder >= Divisor:
      Remainder := Remainder - Divisor
      Quotient := Quotient or 1

Correctness is relatively easy to prove (the loop has the invariant that Dividend = Quotient * Divisor + Remainder, and the post condition that Remainder < Divisor). Signed division in a system with symmetric modulo means figuring out the signs, then running the above algorithm on the absolute values and conditionally flipping signs. Now you know the algorithm so get crackin' with your assembler code. I don't know any m68k assembler, so I can't help you there.

Posted: **Tue Jan 03, 2023 2:27 am**

nullplan wrote:I don't know any m68k assembler, so I can't help you there.

Nor do I, other than what I can copy from what I already have. Yes, I could volunteer to learn it, then volunteer to write it. It's on the list of things I am willing to do, but likely many years away.

Posted: **Tue Jan 03, 2023 12:56 pm**

kerravon wrote:I think GCC is 68020-only, not 68000.

GCC still supports 68000.

Posted: **Tue Jan 03, 2023 3:45 pm**

Octocontrabass wrote:
kerravon wrote:I think GCC is 68020-only, not 68000.
GCC still supports 68000.

Thanks for that.

I tried adding -m68000 to the compile options and got:

amiga.a(stdlib.o)(.text+0x398): undefined reference to `__adddf3'
amiga.a(stdlib.o)(.text+0x44e): undefined reference to `__adddf3'
amiga.a(stdlib.o)(.text+0x56a): undefined reference to `__adddf3'
amiga.a(stdlib.o)(.text+0x5d0): undefined reference to `__adddf3'
amiga.a(stdlib.o)(.text+0x3b8): undefined reference to `__muldf3'
amiga.a(stdlib.o)(.text+0x48e): undefined reference to `__muldf3'
amiga.a(stdlib.o)(.text+0x4e2): undefined reference to `__muldf3'
amiga.a(stdlib.o)(.text+0x426): undefined reference to `__muldf3'
amiga.a(stdlib.o)(.text+0x5be): undefined reference to `__muldf3'
amiga.a(stdlib.o)(.text+0x370): more undefined references to `__muldf3' follow
amiga.a(stdlib.o)(.text+0x500): undefined reference to `__divdf3'
amiga.a(stdlib.o)(.text+0x5a8): undefined reference to `__divdf3'
amiga.a(stdlib.o)(.text+0x4ac): undefined reference to `__subdf3'
amiga.a(stdlib.o)(.text+0x55a): undefined reference to `__floatsidf'
amiga.a(stdlib.o)(.text+0x43e): undefined reference to `__floatsidf'
amiga.a(stdlib.o)(.text+0x388): undefined reference to `__floatsidf'
amiga.a(stdlib.o)(.text+0x466): undefined reference to `__gtdf2'
amiga.a(stdlib.o)(.text+0x8b4): undefined reference to `__divsi3'
amiga.a(stdlib.o)(.text+0x90c): undefined reference to `__divsi3'
amiga.a(stdlib.o)(.text+0x8c2): undefined reference to `__modsi3'
amiga.a(stdlib.o)(.text+0x91a): undefined reference to `__modsi3'
amiga.a(stdlib.o)(.text+0x4c8): undefined reference to `__ltdf2'

(etc)

So there are a stack of things missing if I want to support the 68000 instead of just 68020.

I don't care if floating point is not supported, so the functions just return 0 or garbage.

Posted: **Tue Jan 03, 2023 3:54 pm**

Doesn't libgcc provide all of those functions?

OSDev.org

unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS

Re: unite to make an OS