Oh.... so that is what you meant in the first post! clear now, thanks. (?!?!?)
That was pretty funny, sorry. Go on. ☆PhistucK On Sat, Jul 18, 2009 at 14:58, The Flavored Coffee Guy <[email protected]>wrote: > > I don't have a question. > > I want to revise the ELF file format and includ ELD and ELG. ELD is a > driver, and ELG is like a DLL. The reason for the extensions I will > list for you. > > ELF is the standard Linux exectuable file, it is fine for stand alone > programs. > > ELD is structured differently and meant to be loaded into the expanded > memory for Sound, Video, Accellerators like Video Cards, etc. drivers. > > The header would look like this. > http://www.skyfree.org/linux/references/ELF_Format.pdf > With this added to an exectuable header following the previous headers > in the ELF standard. > > ELD > <Programmer's Text> > <Number of bytes of text for the CPU to ignore in text table> > <Text defining enumeration of Assembly Language Function/Jump Table> > If there is 100 functions in the driver, then there is a list of 100 > long jumps for location in expanded memory. The ELF standard takes > care of relocation, the operating system has to include this table as > well in adoption of those addresses. Because, the Operating system is > going to ignore the programmer's text which is a readable list of > functions that allows any other programmer access to the list of > functions available through the driver. It also defines variable > types and string lengths if any. It's allot of text that is only > important for programmers to know, not the machine to filter through. > Functions are just a list of jump instructions and the addresses the > CPU should start loading a segment of executable code from. The > driver consists of sections of exectuable code that are not written > into programs that directly drive hardware. When any program calls on > it, it only loads the one function requested into the CPU, and doesn't > read the entire executable to reach one function. The list of jump > instructions is the next 100 locations that are enumerated for memory > access points. So, the OS picks up the enumerated table not the text, > jumps to the loading the instructions for the function to the CPU and > executes what may only be a few bytes to the command. When you get > into MIDI functions, or Graphics Acelleration, you'll see that Dither > is really one command just a few bytes, and that will instruct the > coprocessor/GPU to do the job. It makes sense to keep the driver in > the expanded memory, but it doesn't make sense for the CPU to read or > load the whole thing to find one function. This modification should > resolve that. function/end function, sub/end sub operate around the > jump table, which is much like a directory for a bunch of files on a > floppy disk, except it's in binary, used only by the CPU, and just > tells the CPU where the Function starts, and End Function is the exit > to calling routine with result. For a driver, all of the results are > based upon ready and wait from hardware, and the operating system does > the work for the programs by trying again. This usually only amounts > for a few uS delays at times and milliseconds for other cards, it > depends. When you have 64x dual or quad that much is assigned to one > CPU of those that exist on the processor. One should be dedicated to > drivers in that dynamic sense. > > ELG is about the same but is directly associated to a program and only > an ELF can call it up to Load into the expanded memory, and from there > the functions and subs can accessed. Any program that uses an ELG > loads it, and when the program is shut down or exited, the operating > system knows to take that out of memory to free up that memory space > for another program. Then Memory size manages memory as long as the > programs don't absorb it by being 5gig long with all of the associated > files, drivers and data. The extension just places it in expanded > memory as a list of functions and subs where only one of the subs or > functions will load when called upon by the CPU. The bulk of the file > stays in upper memory due to the additional allocation tables that are > not different than the ELD file. The OS recognizes the extension, > therefore when it called upon it just does the relocations, and loads > it into the expanded memory without executing any of it. From that > point it's like a list of mini executables with a file table on > floppy. The difference is that the compiler is packing them with > where the jump instructions/go to statements lead to. > > It's like writing a program like this. > > Goto 1 > Goto 2 > Goto 3 > .... > Goto 100 > > Function 1 > > End Function > > Sub 2 > > End Sub > > .... > > Function 100 > > End Function > > And the operating system basically is programmed to pick up only the > goto statements from the expanded memory, and take them to the CPU, > then call/load the selected function from the expanded memory. Then > the CPU executes the function or sub and hands the result to the > program that called it. > > > Otherwise programs tend to run like Pachinco Ball machines, and the > CPU picks up everything and it bounces around the file executing it > until it gets to the place it really needs to be. Then the CPU read > through over a megabyte of executable code that it didn't need. It's > a program header designed to skip everything you don't use, and be > certain that the CPU and operating system do that to. > > > > > > On Jul 17, 8:28 pm, Benni <[email protected]> wrote: > > What is your question ? > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss -~----------~----~----~----~------~----~------~--~---
