[openbeos] Re: couple o'things

We're going to move it back to the list :) Just for fun :)


At 18:10 24-8-2001 +0300, you wrote:
>ok, let me add a bit more to this thread (be it privately)
>
> > On the kernel timing thing, I do not think NewOS comes really close 
> yet, but then again,
> > it has no AMD/MMX/3DNow optimalisations as far as I know, so that is a 
> major
> > (performance) drawback on most (modern) machines....
>
>a) still one needs to know the exact BeOS kernel figures in order to be 
>able to tell
>by how much a prospective kernel is apart, don't you think?

Don't you think that getting a version *running* and then optimizing it 
heavily might be a better plan of attack? Ok, we need to take this into 
account while coding (not knowingful leave performance holes in the code) 
but this is pretty easy with many coders on the same project, we'll correct 
each other with the relativant experience we have, so making better code 
and *learning how to code better* as an extra added bonus :)

>b) i don't think BeOS kernel has any SIMD optimizations aside from an mmx 
>memcpy.
>but we need to ask Daniel about that.

I can tell you looking at the disasm of the kernel that they use a special 
instruction (not even recognized by the disasm unit of objdump) for doing a 
fast ring 0 gate return back into userspace for some Intel/AMD chips.... 
You can even see this looking at the symbol dump that objdump can give 
you.... They're pretty bleeding obviously called fast_ xxx slow_xxxx 
xxxx_amd, or any other variant you can think of :) Using objdump helps, 
really :)

>as about reference docs,
>
> >Are we actually going to use doxygen? And if so, are we going to make a 
> universal style
> >in how to document the methods / functions / classes / etc? We probably 
> need to decide
> >this before we all start coding like crazy....
>
>i meant that whoever tries to reproduce BeOS will need system reference 
>documents _much_
>better than what the bebook has to offer in its present form. see Marcus' 
>'difficulties...' message
>to the mailing list to get see i mean -- a significant portion of BeOS 
>functionality (on various
>levels and api's) is undocumented.

I meant that we need to capture that info and other information we find out 
while coding in a good format, and close to the relevant code.... Using a 
documentation system that integrates code and doc helps, trust me, I've 
seen it work :)

>-blu
>
>ps: feel free to move this thread to the list :)

Ithamar R. Adema
Information Engineering Associates Ltd
http://www.ieadev.com

Other related posts: