Author: Robert Hyatt
Date: 18:44:29 08/04/03
Go up one level in this thread
On August 04, 2003 at 11:26:36, Vincent Diepeveen wrote: >On August 04, 2003 at 09:43:40, Bo Persson wrote: > >>On August 04, 2003 at 07:59:48, Vincent Diepeveen wrote: >> >>>On August 04, 2003 at 07:43:04, Bo Persson wrote: >>> >>>>On August 04, 2003 at 05:41:55, Vincent Diepeveen wrote: >>>> >>>>>On August 04, 2003 at 04:39:56, Bo Persson wrote: >>>>> >>>>>hi, >>>>> >>>>>it's not so difficult to get a look&feel for it. >>>>> >>>>>a 5 line tool of mine that just prints text out of binary files. so not a >>>>>dissassembler at all. >>>>> >>>>>Kernel32.dll : nothing what i searched for >>>>>winfax.dll : nothing what i searched for >>>>>gpedit.dll : >>>>> >>>>>"normal program termination R6009 - not enough space for environment R6 >>>>>008 - not enough space for arguments R6002 - floating point not loaded >>>>> Microsoft Visual C++ Runtime Library Runtime Error! Program: .. >>>>>. <program name unknown> IsProcessorFeaturePresent KERNEL32 " >>>>> >>>>>Do i need to spell it out? >>>>> >>>> >>>>Yes, please. >>>> >>>>Do you mean that kernel32 does not link to the C library? Surprise. I wonder >>>>what services the C library is linking to... >>>> >>>>On my NT4 machine I can also see than kernel32.dll is 0.3 MB out of the 358 MB >>>>in the /winnt directory. That's about 0.1%, or so. >>>> >>>>I can also see that the hardware interface hal.dll is 51k. Might also contain >>>>lots of assembler code. >>>> >>>>What about the other 300+ MB ? >>> >>>So in your eyes the kernel is 300MB????? >>> >>>are you out of your mind? >> >>:-) >> >>> >>>important is functionality like a program that asks a system function like >>>GetTickCount() >>> >>>Then you want that as quick as possible and C code won't do that for the kernel! >>> >>>Anyway this is all theoretic discussion. >>> >>>It's assembly. >> >>Vincent earlier wrote: >> >>>>I guess they are working hard and basic problem is not only that m$ is 32 bits >>>>in some respects (file systems and such already long period ago 64 bits in 1995) >>>>but especially that their kernel stuff is written in assembly. >>> >> >>>> It is hard for me to understand why so much is in assembler and why there >>>> seemingly is no x bits 'C' version which they can compile on any hardware >>>> with little effort. >> >>Ok, we agree that there is "some assembly required". I can see that it might be >>0.1%, or 0.5%. or even 1.0% of the code base. I wouldn't call that "so much", or >>see that it would be a problem to move it to x86-64 when they have already tried >>it out for Alpha, Itanium, and others. >> >>If you think otherwise, fine. > >you are just guessing a % here. the entire kernel is assembly though. > >let's be clear. i'm not saying that the entire kernel being assembly is a >problem to move it. seemingly reading nalimov's words correctly they have a C >version too, which for the itanium i can consider as being a good idea. writing >assembly for it is a horror. > >For the x86-64 i bet they want an assembly version too, because the platform is >going to be very important. > >You cannot waste registers with a kernel simply. Using regurarly 1 register just >for a processortickcount is already wasting 1 register. So for CPU's with just >16 registers you definitely need assembly for a kernel like NT. That is so utterly stupid that it really doesn't need a rebuttal. But, for fun, "that was a stupid remark." In an O/S we _do_ "waste" registers whenever possible. Registers are faster than memory accesses. We do the _same_ sort of optimizations in an O/S that we do in any other time-critical programming exercise. > >just consider how much software most people have installed. it only adds up and >they all regurarly query the kernel. Do you _really_ know what the "kernel" is? Programs don't "regularly query the kernel" unless they do a lot of I/O. This is just showing your ignorance of how an O/S works. > >linux does not have such problems. there is hardly software working for it! Right. No high-performance server applications, database applications, programming applications, chess applications, CAD/CAM applications, graphics applications. It's hard to guess whether your ego or your ignorance is larger, at the moment. They are running "neck and neck." > >>Bo Persson >>bop2@telia.com
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.