Buzza

• The Future of SQL Data Services with Nigel Ellis

  Apr 27, 2009 at 3:09 PM

  Is there any type of concurrency manager in the cloud ?

• Brian Jones - New Office file formats announced

  Jun 02, 2005 at 5:56 AM

  TomRaftery wrote:

  This all sounds great but can anyone tell me how is this any different from how OpenOffice is handling files right now?
  
  Tom
  

  
  
  I don't know - and really, no client that I know of has used open office, so I don't really care.

• Singularity: A research OS written in C#

  May 24, 2005 at 10:15 PM

  Beer28 wrote:

  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.

• Singularity: A research OS written in C#

  May 24, 2005 at 7:56 PM

  Beer28 wrote:

  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.

• Singularity: A research OS written in C#

  May 15, 2005 at 2:21 PM

  Again, I don't think NEW would be implemented in c# but probably in low level assembler - same as the GC?

• Singularity: A research OS written in C#

  May 15, 2005 at 12:59 PM

  Beer28 wrote:

  
  
  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.

• Singularity: A research OS written in C#

  May 15, 2005 at 12:45 PM

  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.
  
  I found this site about another OO language called Oberon:
  
  http://www.oberon.ethz.ch/native/
  
  Where they discuss memory management in another type of OS called Oberon.  It's also a OO language.
  
  http://www.oberon.ethz.ch/native/WebHeap.html
  
  They discuss memory allocation.  This is most likely what these guys did.
  

• Singularity: A research OS written in C#

  May 14, 2005 at 3:14 PM

  Beer28 wrote:

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

  
  
  I have a Motorolla 68HC11 test board I want to get rid of, if you're feeling nostalgic and you want a good clean one for twenty bucks, let me know.
  

  
  
  Na, have done the stuff for 10 years - and i hated doing wire wrap (mine was wire wrap anyway)

• Singularity: A research OS written in C#

  May 14, 2005 at 1:25 AM

  Beer28 wrote:

  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.
  
  I assume that this environment would only run managed code.

• Singularity: A research OS written in C#

  May 14, 2005 at 1:14 AM

  staceyw wrote:

  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.
  
  Could this be a purely OO OS?

See more comments…