Buzza wrote:I class it as a dirty trick as a pointer is just that - it points to data - but it is not the actual data - the data is what is pointed at that memory location. An integer is data - not a pointer. Keep the 2 seperate.

in assembly it doesn't matter, C is shorthand for assembly

it's 32 bits either way. All those types in windef.h are all typedefs, they are not compiler standard types. WORD, DWORD, WPARAM, all that stuff.A pointer to a type and an int are compiler types, they happen to be the same size on x86, long and * are the same size on x86_64.

That's not cheating, that's programming. If you ever do small MCU's with limited addresses, you will quickly see, that you need addressability.

Managed code like java is a whole other story. You can't say C or C++ code is dirty because it doesn't behave like java. It's not supposed to.

They key word here is 'happen to be the same size on x86' thats the dirty word as its just a coincidence.

Could you give me a sample of this 'addressability', as being a c and c++ dev - i have never needed it.

larus wrote:an unsound assumption that a program isn't violating language semantics with dirty tricks, such as converting an integer to a pointer.

I never thought of using pointers as integers a dirty trick....in x86 they're the same width so it doesn't really matter in the compiled code nor asm which is which type. I guess the same is true on 64 with long.

Do you have any plans for embedded systems, 8051/2, arm?what about just arm? I don't forsee this going to 8 or 16 bit in short retrospect.

I class it as a dirty trick as a pointer is just that - it points to data - but it is not the actual data - the data is what is pointed at that memory location. An integer is data - not a pointer. Keep the 2 seperate.

like C++ or java, new is part of the language, it's a keyword, malloc is not, heap allocation and freeing is actually embedded in the language specs.

that should have been C++, java and C# - and as you said there is no malloc / free in these languages - they in the specs - which leads me to believe thats where the implementation is, at the low level implemenation of the CLR runtime subset.

What I think you need to do is forget about malloc and free and look at what these functions do.

New is part of the framework and free is implemented via the GC - in regards to what the functions do - they are extrememly simple and most likely implemented in assem - remember they said they dropped down to assem for parts.

The huge difference between C, C++, Perl, and java || C# is that the latter 2 have memory management through a garbage collector and cannot directly access memory pointers.

Perl5 uses reference counting. Perl6 will use Parrot.

If the compiler links all the runtime support as one huge linkable monolith binary then fine, that's what gcj does, except it's shared, and not usually statically linked. In a kernel though you'd have to link it statically.

Case in point, one of the people in the video responded and wrote, in libc, you have functions written with C, but in their kernel you have functions equivalent to libc written with C#.

How are you going to write a malloc routine with C#?

You have to allocate memory at some point in a kernel, you have to have some IO and communication with devices through shared memory. You have to use memory addresses, you have to load the ivt with the entry points of your int handlers.

C# won't let you manipulate memory pointers. There has to be something else there. That big runtime bartok links your C# to must be full of C code.

C# can't do these things because of the language, so yes it differs from C/C++ and Perl.

EDIT: Or say you get an interupt and god forbid your x86 compiled C# handler must pull values out of registers to handle it. C# has no such functionality, and you can't drop to asm.

What is the stack - a place to store data, its gets pushed, and gets poped. There is the stack object in .net and works the same way - its not the same actual stack - but the functionality of it is exactly the same.

I think of it as mananged code at the lowest of levels that anyone will ever want to get at.

instead of alloc and free - we can use new and (!Dispose() or the GC)

registers / stack / etc are so low level - last time I touched them was when i was doing control electronics on a 68HC11.

I would class this as the lowest level of machine virtualisation with the focus in OO princibles.

There are 2 large differences. You can compile C code without importing anything, thus making it independant. The 2nd difference is that you can statically compile in both the C and C++ runtimes.

I see no practicle difference here. If you can do it in C, you can do it in any language as long as you have the compiler support. That language itself does not matter. You could do it in Perl as long as you had the support to convert the MSIL into native
code to run on the bare metal (which is what Bartok does AFAICT).

The difference is there is a managed environment at the kernal level. The ref counts / type safety is available at a much level lower.

EDIT: i forgot to mention the runtime takes care of what the compiler used to do with type safety and references counting.

ALLOC and FREE are just c function in stdlib (i think) - they are just replaced with NEW and the GC - its a very impressive design.

Buzza wrote:They have the GC and strong typing at the kernal level. Jim said that he did away of the stuff they didn't need - the different ways to compare strings in the different languages (is there a difference between comparing
strings in a language - a string is a string ??) There is also no JIT - so it would be like running NGEN on the OS.

EDIT: NGEN pre-JIT's your code base

galenh wrote:

This isn't the CLR. In our world, we compile entire MSIL for the kernel into x86 instructions at installation time. There is no libc at the bottom.

He says there's no CLR. The clr would need the real kernel and libc anyway. It sounds like they're compiling the C# code to native instructions the way a C compiler would with a library that it uses to do io and memory access.

What do you think Buzza?

The base class libraries are not there - as he said Windows Forms and XML are not need (and probably need to much work to get it to work anyway)

They probably got the open source 'rotor' project and used that as the basis for their - lets call it the kernal runtime. This could then have been modifed down to the assem level to talk to the bios. Once this bios - managed layer was complete - they moved
on and created the rest of the microkernal components.

EDIT: there is no clr as we know it - but there is a 'managed environment' down there - they do have a GC at that level - or thats the impression i got from the interview. In the end - everything turns into assem - its just at what stage do we create the assem
?

Is it possible to have the kernal look after the GC and strong typing for use ? I think it is ! With the kernal - malloc and free are replaced by the new and the Garbage Collector ??

From what I gather from the video - they used a cut down version of the clr - except for the low level assem stuff.

They have the GC and strong typing at the kernal level. Jim said that he did away of the stuff they didn't need - the different ways to compare strings in the different languages (is there a difference between comparing strings in a language - a string is
a string ??) There is also no JIT - so it would be like running NGEN on the OS.

Java had a similar go at trying to create a Java OS desktop some time ago ? Anyone know how that went?

I like the idea of this OS, but it will not replace windows anytime soon. But could replace things like Windows CE / SmartPhone etc (aren't these all os's ?)