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 -~----------~----~----~----~------~----~------~--~---
