Just to make sure we are all on the same page, the point of having
native libs is so that we can have a better start up time (i.e. True
Type fonts, MySQL client, etc.). In the end (2 years on, or whatever)
we should pull the support out of the compiler: or leave it in as a
enduring experimental fea
Hi Iraklis,
Welcome to the mailing list. I can't suggest an activity for you
and I'm sure others feel the same way. If you want to contribute,
just read the mailing list and if an interesting topic crops up
that you think is worthwile to pursue, go ahead and get involved
there.
There's a lot of w
Hi Jonathan,
Inlining native libraries is difficult to say the least. I have not
thought about it as I consider this really dangerous to say the least.
You'd have to process all emitted code and either link with the external
library or copy the code from it. Finally these libraries aren't standal
Hi Bruce,
Answers inline.
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von Bruce Markham
> Gesendet: Dienstag, 5. August 2008 17:22
> An: sharpos-developers@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] MOSA / AOT
>
> Okay,
On Tue, Aug 5, 2008 at 8:22 AM, Bruce Markham <[EMAIL PROTECTED]> wrote:
>
> MOSA needs a domain. MOSA needs a mailing list. MOSA needs *people*. Then,
> I think, MOSA can sit down to create standards.
>
You are correct and we are working on it. We already got a domain already
and we are working
Okay, before anyone starts marking their scents on the ground - (I'm
stopping you so I can get mine in there first) - my point isn't what looks
pretty or doesn't.
My point is, MOSA needs to agree on how to handle (and how much to handle)
differing paradigms. Grover, I'm glad you think you agree wi
> tells the compiler here's special code to emit. I've read Chad's entry
> about
> X#, but sadly think this appears nice at first, but causes a lot of
> headaches afterwards.
Actually it has worked very well for us. It's a 1:1 mapping, its not a
compiler more of a Mnemonic system. There is no way
Hi Bruce,
Actually everything you said is my personal belief. And everything you wrote
is already in the design of the compiler. Native operations are handled by
marking properties, fields or methods with an Intrinsic attribute, that
tells the compiler here's special code to emit. I've read Chad's
Well, like I said several e-mails back in this thread - MOSA needs to start
talking about standards. Adding another compiler to the list, (whether call
it a MOSA compiler or not, and whether we think it will be less confusing to
maintain or not), doesn't solve any lasting problems.
I was working o
I said this on the Cosmos ML, I suppose I should have said it
everywhere. The point of this TTF stuff is that I will co-incide with
completion of System.Drawing namespaces (and the start of userland as
a whole). It will rely heavily on Regions and Paths and what not, we
will need those types of thi
I can vouch that IL2CPU is a good compiler. Only thing is that a lot
of your code doesn't 'fit' into it. I don't think you would be able to
compile your stuff without a lot of work (shy of a total re-write).
On Tue, Aug 5, 2008 at 2:11 PM, Chad Z. Hower aka Kudzu <[EMAIL PROTECTED]>
wrote:
>> Whi
Most likely it is. I have not invested much time in it.
Mike
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von Chad Z. Hower aka Kudzu
> Gesendet: Dienstag, 5. August 2008 14:11
> An: sharpos-developers@lists.sourceforge.net
> Betreff: Re
> Which could be used, but has its fair share of issues too. I'm certain
> that
I think its much farther along than you think
> design AFAIK, as there's no support for Attributes, Reflection, ...
They haven't been high on the list because we haven't needed them yet.
-
> Don't the other teams, or at least the Cosmos, have compilers as well?
Yes, Cosmos has a full compiler.
> Although they're not designed as well in the basis as the AOT, maybe
> we could 'borrow' one of these compilers for the time being until the
> MOSA compiler is finished?
If you can live wi
On Tue, Aug 5, 2008 at 12:38 PM, Zachary Gorden
<[EMAIL PROTECTED]> wrote:
> In response to Sander:
>
> A valid point, regarding the reserved space. However, I was thinking that
> the drivers were also restricted to the upper 2GB with the kernel.
> Actually, this is the point where you guys tell m
Hi everyone,
since I'm new I'll introduce myself a bit. My name is rootnode (Simon
Wollwage)
and I'm helping grover with the MOSA compiler.
I'm a B.Sc. student of computer science and mathematics in my 5th
semester at RWTH Aachen University, Germany. So far about my background.
Thath's all for
That's exactly what i was talking about before, when talking about
keeping "book-keeping information" in memory when swapping pages to
disk.
That way you know if blocks of memory (which are currently on disk)
need to be collected or not.
This way you wouldn't even have to touch the memory blocks...
I am new here, i am 16 years old. i know c, vb6, vb.net and now i am learnig
c#.
i dont know thinks about the kernel but i want to help.
so what do u suggest me?? from where to start?? thanks :)
PS
sorry for my english i speak them in the greek way :)
Iraklis Karagkiozoglou
-
Zach,
You're right. Current GCs tend to trash the disk if they try to
collect a heap that's mostly paged out. I was hoping we can
prevent this kind of behavior by applying some smarts there. Actually
I think the chances are actually good there as pages could be removed
from memory on a LRU scheme
In response to Sander:
A valid point, regarding the reserved space. However, I was thinking that
the drivers were also restricted to the upper 2GB with the kernel.
Actually, this is the point where you guys tell me how you want to approach
this separation of drivers thing. After all, sticking al
Hi Zach,
Some answers inline below.
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von Zachary Gorden
> Gesendet: Dienstag, 5. August 2008 09:39
> An: sharpos-developers@lists.sourceforge.net
> Betreff: [SharpOS Developers] Additional stuff
We can continue development with the AOT. I have never asked for anything
else. It is my opinion that we should continue with it, refactor and
redesign the existing code base and use the time to sit down and do basics
like you do with memory management.
Mike
_
Von: [EMAIL PROTECTED]
[
Hi Sander,
There's only two options available IMHO:
1. IL2CPU from Cosmos
Which could be used, but has its fair share of issues too. I'm certain that
we could get further with it than the AOT, but we still can't do an advanced
design AFAIK, as there's no support for Attributes, Reflection, ... H
Cool, good to see that someone has put some time into the basics of a design.
My responses are meant as positive criticism, and meant to start a
dialog, not to force my opinion onto anyone. I -expect- people to come
up with counter arguments. Hopefully trough this dialog we can come up
with a good
Yes, but the problem is that the AOT is missing some functionality, or
has some bugs, which prevent us in properly implementing some parts of
the kernel.
In a way, we're kinda stuck and can't go forward because of it.
So either we fix those bugs in the AOT, and implement those features
that we need
Even if the intention is to replace the AOT, there shouldn't be any reason
to not continue development using it right now. The code should still
compile with a new compiler.
-
This SF.Net email is sponsored by the Moblin Your
Decided to get off my ass and provide some more detailed thoughts about
what's needed for the memory system. So far, this is more a matter of
intentions than set plans. It also raises some points I don't fully
understand and would appreciate insight on.
SharpOS Memory Architecture Design
This i
27 matches
Mail list logo
