• Matthew (8/8) Jan 05 2004 First, does D have the concept of a single-threaded build, or is everyth...
• Walter (9/18) Jan 06 2004 everything
• C (7/25) Jan 06 2004 I think DIG has done this, runs colletctions every now and then. Might ...
• Matthew (10/28) Jan 06 2004 How about having a trap in the threads module that creates the low-prior...
• Walter (6/12) Jan 15 2004 low-priority
• Matthew (6/19) Jan 16 2004 will
• Clint Olson (20/26) Jan 08 2004 But aren't there some cases where DMD will not build an object file with...
• Clint Olson (4/32) Jan 08 2004 Whoops, I lied. I have a tiny amount of non-D code, in assembler, that ...
• John Reimer (7/11) Jan 08 2004 Bravo, nonetheless!
• Clint Olson (7/16) Jan 08 2004 The asm code I'm using was basically borrowed from the GRUB documentatio...
• Ant (12/17) Jan 08 2004 You mean WAS over...
• C (22/52) Jan 08 2004 His last post was not long ago ( a month ? ) so hes still around.
• Walter (22/51) Jan 15 2004 thread
• Clint Olson (29/82) Feb 05 2004 There's nothing wrong with it, I was just trying to figure out if I coul...
• Walter (3/4) May 13 2004 No, it does not.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

First, does D have the concept of a single-threaded build, or is everything
multi-threaded? (Hopefully the latter)

If the process is multithreaded, does a background thread kick the GC every
now and then when the other threads are idle? One of the things that I think
stinks about .NET is the fact that collection only ever happens in
low-memory conditions. Why not have a low-priority background thread, that
will rightly be pre-empted by any other threads in the machine, that does it
when the machine is in quiescent state?

"Walter" <walter digitalmars.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

 If the process is multithreaded, does a background thread kick the GC

every
 now and then when the other threads are idle?

No. A collect is done when an allocation is requested. One could, however,
spawn a very low priority thread that will do a collection. What I like to
do is in the 'idle' part of the command loop, put the call there.

 One of the things that I think
 stinks about .NET is the fact that collection only ever happens in
 low-memory conditions. Why not have a low-priority background thread, that
 will rightly be pre-empted by any other threads in the machine, that does

it
 when the machine is in quiescent state?

"C" <dont respond.com> writes:

I think DIG has done this, runs colletctions every now and then.  Might give
it a gander.

C
"Walter" <walter digitalmars.com> wrote in message
news:btfl3v$2cs3$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

 everything
 multi-threaded? (Hopefully the latter)

 Everything is multithreaded.

 If the process is multithreaded, does a background thread kick the GC

 every
 now and then when the other threads are idle?

 No. A collect is done when an allocation is requested. One could, however,
 spawn a very low priority thread that will do a collection. What I like to
 do is in the 'idle' part of the command loop, put the call there.

 One of the things that I think
 stinks about .NET is the fact that collection only ever happens in
 low-memory conditions. Why not have a low-priority background thread,


that
 will rightly be pre-empted by any other threads in the machine, that


does
 it
 when the machine is in quiescent state?

"Matthew" <matthew.hat stlsoft.dot.org> writes:

How about having a trap in the threads module that creates the low-priority
collecting thread only if something calls into the thread library and
creates a thread?

That way, people who don't want to have any more than the main thread will
not have it forced on them, but those that are creating multiple threads
will get this behaviour for free.

"Walter" <walter digitalmars.com> wrote in message
news:btfl3v$2cs3$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

 everything
 multi-threaded? (Hopefully the latter)

 Everything is multithreaded.

 If the process is multithreaded, does a background thread kick the GC

 every
 now and then when the other threads are idle?

 No. A collect is done when an allocation is requested. One could, however,
 spawn a very low priority thread that will do a collection. What I like to
 do is in the 'idle' part of the command loop, put the call there.

 One of the things that I think
 stinks about .NET is the fact that collection only ever happens in
 low-memory conditions. Why not have a low-priority background thread,


that
 will rightly be pre-empted by any other threads in the machine, that


does
 it
 when the machine is in quiescent state?

"Walter" <walter digitalmars.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btg1b6$pc$1 digitaldaemon.com...
 How about having a trap in the threads module that creates the

low-priority
 collecting thread only if something calls into the thread library and
 creates a thread?

 That way, people who don't want to have any more than the main thread will
 not have it forced on them, but those that are creating multiple threads
 will get this behaviour for free.

The library is multithreaded regardless of whether the programmer creates
multiple threads or not. In any case, a low priority thread doing gc doesn't
really add much.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bu850e$2gd9$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btg1b6$pc$1 digitaldaemon.com...
 How about having a trap in the threads module that creates the

 low-priority
 collecting thread only if something calls into the thread library and
 creates a thread?

 That way, people who don't want to have any more than the main thread


will
 not have it forced on them, but those that are creating multiple threads
 will get this behaviour for free.

 The library is multithreaded regardless of whether the programmer creates
 multiple threads or not. In any case, a low priority thread doing gc

doesn't
 really add much.

Doesn't it execute finalisers? That could release other kinds of resources,
and free up resources

Clint Olson <Clint_member pathlink.com> writes:

In article <btfl3v$2cs3$1 digitaldaemon.com>, Walter says...
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

But aren't there some cases where DMD will not build an object file with thread
related code?  Possibly when no language features that require GC are used?
Possibly this is really an issue of how the D compiler is implemented?
Different D compilers will have a different answer this question?

This has been of particular interest to me since I'm toying around with writing
an OS in D without modifying DMD in any way.  A previous effort in this area by
Mike Wynn included hacking phobos, but I expect he was trying to retain most of
D's features.  His effort was discussed a bit in previous posts. Unfortunately
Mike seems to have disappeared, even though his geocities pages are still up, so
I've been unable to bounce my idea off of him.

I'm mostly a Java programmer, so OS development is way over my head, but if I'm
going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy
:)

I've successfully booted to a rediculously incomplete kernel which does nothing
but print to the console (not even keyboard interrupt handling yet).  The kenel
code uses modules, but not classes. The kernel was built using DMD as the
compiler with the -c option and (ofcourse) gcc with link options that exclude
everything but code I've written in D.  I wouldn't think this possible if DMD
always created multithreaded object files.

Clint Olson <Clint_member pathlink.com> writes:

In article <btk998$dau$1 digitaldaemon.com>, Clint Olson says...
In article <btfl3v$2cs3$1 digitaldaemon.com>, Walter says...
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

But aren't there some cases where DMD will not build an object file with thread
related code?  Possibly when no language features that require GC are used?
Possibly this is really an issue of how the D compiler is implemented?
Different D compilers will have a different answer this question?

This has been of particular interest to me since I'm toying around with writing
an OS in D without modifying DMD in any way.  A previous effort in this area by
Mike Wynn included hacking phobos, but I expect he was trying to retain most of
D's features.  His effort was discussed a bit in previous posts. Unfortunately
Mike seems to have disappeared, even though his geocities pages are still up, so
I've been unable to bounce my idea off of him.

I'm mostly a Java programmer, so OS development is way over my head, but if I'm
going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy
:)

I've successfully booted to a rediculously incomplete kernel which does nothing
but print to the console (not even keyboard interrupt handling yet).  The kenel
code uses modules, but not classes. The kernel was built using DMD as the
compiler with the -c option and (ofcourse) gcc with link options that exclude
everything but code I've written in D.  I wouldn't think this possible if DMD
always created multithreaded object files.

Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that conforms
to the "mutliboot standard" so that grub can interface with it. It simply calls
my kernel entry point.

John Reimer <jjreimer telus.net> writes:

 
 Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that
conforms
 to the "mutliboot standard" so that grub can interface with it. It simply calls
 my kernel entry point.

Bravo, nonetheless!

I was wondering about the asm part. I assumed at least a little asm code
would be necessary.  But I thought all OS's needed that, so the lie is
forgivable:). How did you code the assembler portion? Did you put it in a
D asm code block?

Nice work!

- John

Clint Olson <Clint_member pathlink.com> writes:

In article <pan.2004.01.08.22.31.52.199273 telus.net>, John Reimer says...
 
 Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that
conforms
 to the "mutliboot standard" so that grub can interface with it. It simply calls
 my kernel entry point.

Bravo, nonetheless!

I was wondering about the asm part. I assumed at least a little asm code
would be necessary.  But I thought all OS's needed that, so the lie is
forgivable:). How did you code the assembler portion? Did you put it in a
D asm code block?

The asm code I'm using was basically borrowed from the GRUB documentation and is
not in a D asm code block.  I haven't used a D asm code block yet becuase I'm
not very far along and because its not necessary for manipulating the VGA
console, which uses normal memory, rather than I/O memory.

But you are obviously right that an OS endeavor won't get very far without some
asm blocks :)

Ant <Ant_member pathlink.com> writes:

In article <btk998$dau$1 digitaldaemon.com>, Clint Olson says...
I'm mostly a Java programmer, so OS development is way over my head, but if I'm
going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy
:)

You mean WAS over...
maybe the other guys are the crazy ones ;)

I've successfully booted to a rediculously incomplete kernel which does nothing
but print to the console (not even keyboard interrupt handling yet)

ah! brave new world!
can you share that?
the more incomplete the better - means less to look at.
just curious.

When I was done with the book "Design your own C compiler in C"
(or some thing like that) I got another called 
"Build your own OS" but then I got my first job and...
anyway Mr. Torvalds got there first.

Ant

"C" <dont respond.com> writes:

I would LOVE to see an OS in D.  I think that would 100% ensure its success.

 Mike seems to have disappeared, even though his geocities pages are still

up, so
 I've been unable to bounce my idea off of him.

His last post was not long ago ( a month ? ) so hes still around.

Thats awesome u got it to boot I didn't realize it had gotten even that far.
I have NO OS experience but if you get into it i'd defintly try to help (
emphasis on try ;) ).

C

"Clint Olson" <Clint_member pathlink.com> wrote in message
news:btk998$dau$1 digitaldaemon.com...
 In article <btfl3v$2cs3$1 digitaldaemon.com>, Walter says...
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

 But aren't there some cases where DMD will not build an object file with

thread
 related code?  Possibly when no language features that require GC are

used?
 Possibly this is really an issue of how the D compiler is implemented?
 Different D compilers will have a different answer this question?

 This has been of particular interest to me since I'm toying around with

writing
 an OS in D without modifying DMD in any way.  A previous effort in this

area by
 Mike Wynn included hacking phobos, but I expect he was trying to retain

most of
 D's features.  His effort was discussed a bit in previous posts.

Unfortunately
 Mike seems to have disappeared, even though his geocities pages are still

up, so
 I've been unable to bounce my idea off of him.

 I'm mostly a Java programmer, so OS development is way over my head, but

if I'm
 going to do it, I prefer a stripped down D function set over C.  Maybe I'm

crazy
 :)

 I've successfully booted to a rediculously incomplete kernel which does

nothing
 but print to the console (not even keyboard interrupt handling yet).  The

kenel
 code uses modules, but not classes. The kernel was built using DMD as the
 compiler with the -c option and (ofcourse) gcc with link options that

exclude
 everything but code I've written in D.  I wouldn't think this possible if

DMD
 always created multithreaded object files.

"Walter" <walter digitalmars.com> writes:

"Clint Olson" <Clint_member pathlink.com> wrote in message
news:btk998$dau$1 digitaldaemon.com...
 In article <btfl3v$2cs3$1 digitaldaemon.com>, Walter says...
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

 But aren't there some cases where DMD will not build an object file with

thread
 related code?

Not really sure what you mean. What's wrong with multithread capability
anyway?

  Possibly when no language features that require GC are used?

?? GC is not really wrapped up in the multithreading issue.

 Possibly this is really an issue of how the D compiler is implemented?

No. How the compiler itself is implemented and how the runtime library works
are independent.

 Different D compilers will have a different answer this question?

I don't really see how.

 This has been of particular interest to me since I'm toying around with

writing
 an OS in D without modifying DMD in any way.  A previous effort in this

area by
 Mike Wynn included hacking phobos, but I expect he was trying to retain

most of
 D's features.  His effort was discussed a bit in previous posts.

Unfortunately
 Mike seems to have disappeared, even though his geocities pages are still

up, so
 I've been unable to bounce my idea off of him.

 I'm mostly a Java programmer, so OS development is way over my head, but

if I'm
 going to do it, I prefer a stripped down D function set over C.  Maybe I'm

crazy
 :)

Sure you can strip down the library. But that would not affect the compiler.

 I've successfully booted to a rediculously incomplete kernel which does

nothing
 but print to the console (not even keyboard interrupt handling yet).  The

kenel
 code uses modules, but not classes. The kernel was built using DMD as the
 compiler with the -c option and (ofcourse) gcc with link options that

exclude
 everything but code I've written in D.  I wouldn't think this possible if

DMD
 always created multithreaded object files.

There is some misunderstanding here about what a multithread object file is.

Clint Olson <Clint_member pathlink.com> writes:

In article <bu850f$2gd9$2 digitaldaemon.com>, Walter says...
"Clint Olson" <Clint_member pathlink.com> wrote in message
news:btk998$dau$1 digitaldaemon.com...
 In article <btfl3v$2cs3$1 digitaldaemon.com>, Walter says...
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95p$1o1a$3 digitaldaemon.com...
 First, does D have the concept of a single-threaded build, or is

everything
 multi-threaded? (Hopefully the latter)

Everything is multithreaded.

 But aren't there some cases where DMD will not build an object file with

thread
 related code?

Not really sure what you mean. What's wrong with multithread capability
anyway?

There's nothing wrong with it, I was just trying to figure out if I could build
an executable that didn't rely on calls to the underlying OS, which I assume
threads, and therefore GC, require.

Unless my experiments in OS development in D are not comprehensive enough (quite
possible) it seems that one can create executables in D that are not
multithreaded.  Otherwise, I would not be able to link my DMD created object
files without the pthreads library (what Phobos uses in Linux?).

Maybe I should think of it this way.  D is the combination of a compiler and a
library.  While the library may be multithreaded, the compiler doesn't care one
way or the other if you use the library.  The best way for me to avoid getting
caught using features of the D language that require calls to an underlying OS
is to eliminate phobos from the development process altogether.

This obviously means that several language features, like classes, are out,
since object.d is part of phobos.  Now I'm starting to see why Mike Wynn was
hacking phobos to create his d-kernel.

  Possibly when no language features that require GC are used?

?? GC is not really wrapped up in the multithreading issue.

Except that GC runs in a separate thread. right?

 Possibly this is really an issue of how the D compiler is implemented?

No. How the compiler itself is implemented and how the runtime library works
are independent.

Hey, that's what I said above.  Sorry, I'm really showing my ignorance by not
catching on to this sooner.  Maybe too much Java, where the runtime and library
are unavoidable, has adversly affected my brain...

 Different D compilers will have a different answer this question?

I don't really see how.

 This has been of particular interest to me since I'm toying around with

writing
 an OS in D without modifying DMD in any way.  A previous effort in this

area by
 Mike Wynn included hacking phobos, but I expect he was trying to retain

most of
 D's features.  His effort was discussed a bit in previous posts.

Unfortunately
 Mike seems to have disappeared, even though his geocities pages are still

up, so
 I've been unable to bounce my idea off of him.

 I'm mostly a Java programmer, so OS development is way over my head, but

if I'm
 going to do it, I prefer a stripped down D function set over C.  Maybe I'm

crazy
 :)

Sure you can strip down the library. But that would not affect the compiler.

Got it.

 I've successfully booted to a rediculously incomplete kernel which does

nothing
 but print to the console (not even keyboard interrupt handling yet).  The

kenel
 code uses modules, but not classes. The kernel was built using DMD as the
 compiler with the -c option and (ofcourse) gcc with link options that

exclude
 everything but code I've written in D.  I wouldn't think this possible if

DMD
 always created multithreaded object files.

There is some misunderstanding here about what a multithread object file is.

Quite possibly.  I guess I meant object files with calls to a thread library.
Bottom line, it is possible create object files with DMD which do not make calls
to the underlying OS for threading, GC, or anything else.  While many portions
of phobos do not require calls to the underlying OS, a brute force method to
preclude calls to the underlying OS would be to eliminate phobos from the
compile and link steps.  (and ofcourse, not to include any other libraries that
also required calls to the underlying OS).

Sound about right?

"Walter" <newshound digitalmars.com> writes:

"Clint Olson" <Clint_member pathlink.com> wrote in message
news:bvucj5$ukt$1 digitaldaemon.com...
 Except that GC runs in a separate thread. right?

No, it does not.