On Nov 16, 2007 1:52 AM, Jonathan Chayce Dickinson <[EMAIL PROTECTED]>
wrote:
> Hey All,
>
>
>
> I was thinking about a new approach to this whole topic. Has anyone worked
> with DSLs before? We could write a DSL->IL (DSL compilers are easy to write
> because the programmer non-intuitively parses the code as he writes it)
> compiler that is far more efficient than a C# compiler. We would then be
> able to concentrate on the architecture of the Kernel instead of the
> implementation.
>
>
>
> I have also been thinking. We need to extend MSIL to allow for assembler
> commands (or am I lost, are they already there?). Something like the
> following:
>
>
>
> ... IL
>
> asm{
>
> mov ax, bx
>
> }
>
> ret
>
>
>
> Our legendary AOT man could then do a simple replacement on the IL when he
> compiles it, e.g. (excuse the IL, I haven't worked with it enough):
>
>
>
> Ld.arg Foobar
>
> Asm
>
> {
>
> pop ax
>
> }
>
> Ret;
>
>
>
> Would become:
>
>
>
> Asm
>
> {
>
> Push (address of foobar)
>
> }
>
> Asm
>
> {
>
> Pop ax
> }
>
> Asm
>
> {
>
> Ret
>
> }
>
>
>
> Which would then become:
>
>
>
> Asm
>
> {
>
> Push (address of foobar)
>
> Pop ax
>
> Ret
>
> }
>
>
>
> What you all think? The IL would simply get a new construct:
>
>
>
> ASM ::= <0xFA> [int8 length]
>
>
>
> Which could be chained if the ASM is longer than 256 bytes. E.g.
>
>
>
> 0xFAFF [256 bytes of assembler] 0xFAFF [256 bytes of assembler] 0xFA01 [1
> byte of assembler].
>
>
>
> ^^ Is actually one assembler block. This is how some binary XML
> serializers work.
>
>
>
> **Do I finally I have write access to the sandbox?**
>
>
>
> Jonathan Chayce Dickinson
>
>
>
Well, a couple things.
We have already worked around the ASM issue. DarxKies designed the AOT such
that there are a plethora of ASM stub methods (one for each ASM statement),
that the kernel "calls". When the AOT compiles the kernel's IL into x86 ASM,
it converts these stub method calls into real ASM statements.
This is how we've pulled off interrupt handling, and other low-level
functionality. Naturally, in the long run, only the core of the kernel will
have this mechanism available to it, and drivers and such will rely on
abstractions and message passing to the kernel, in order to have their dirty
work done.
But we aren't retooling IL. Its too much work, and it takes us out of the
domain of being compatible with industry tools like Mono and MS .NET.
Also, application of Domain Specific Languages would also take us away from
our core goal of using C#. Since C# and normal IL are not hindrences to us,
we have no need to veer away. And if we did, it would reduce the usefulness,
and also the "special-ness" of our project.
Unfortunately, under SourceForge, SVN access cannot be restricted. Its
either an all-in or all-out deal, so we have to limit SVN access to core
contributors and maintainers, in order for us to remain sane. After you've
made some significant code contributions, and demonstrated familiarity with
the kernel and/or the AOT, we can talk more about getting you sandbox
access.
In the mean time, feel free to continue lending your design thoughts, and if
you have code change suggestions, post a .patch to the mailing list and we
can review it.
-Bruce
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
