running a program
-
jack
running a program
okay maybe something about this is obvious because I haven't seen it talked about much ... If you have program information loaded into memory (I'm assuming this is just a list of opcodes) how does the operating system go about executing it? It seems to run an operation you'd have to interpret the opcode or something into an assembler instruction but I couldn't find any kind of interpretation like this in the source I've been reading over.
-
carbonBased
RE:running a program
You might want to do a little more research into operating systems and assembly language before trying to write your own OS, dude...
OpCodes _ARE_ assembler instructions... they're the binary equivalents, which are readable by the processor. You don't have to interpret them, that's what the processor itself it for.
If you've loaded an executable into memory, all you have to do (essentially) to run it is to jump to its entry point.
Of course there are other complications... setting up P0...P3 stacks, valid selectors, and so on, but that's it, in a nutshell.
Jeff
OpCodes _ARE_ assembler instructions... they're the binary equivalents, which are readable by the processor. You don't have to interpret them, that's what the processor itself it for.
If you've loaded an executable into memory, all you have to do (essentially) to run it is to jump to its entry point.
Of course there are other complications... setting up P0...P3 stacks, valid selectors, and so on, but that's it, in a nutshell.
Jeff
-
timmer
RE:running a program
I had no Idea that opcodes were in fact the asm keywords. Guess us computer science majors learn something every day (us that only learn high level languages)
-
Schol-R-LEA
RE:running a program
I believe what CarbonBased meant was the assembly instructions are directly equivalent to the opcodes they represent - which isn't *quite* right. Some mnemonics actually represent several different opcodes, while some opcodes have more than one mnemonic; some opcodes incorporate a code for the register(s) used
The real point is that the opcodes are what the CPU runs directly; there's no further software interpretation (unless you count the firmaware as an interpreter). The 'interpreter' for opcodes is in the hardware itself.
However, as I pointed out on the Mega-Tokyo site (where Jack asked the same question), what he really seems to be asking about is the procedure for loading an executable file. While this usually involves a certain amount of run-time patching of address information for most relocatable program formats, in principle it could be as simple as copying the file into a specific area of memory and jumping to it. THat is exactly what DOS does with .com files.
This can be a pretty complicated issue, actually. The best book I know of on it is _Linkers and Loaders_ by John Levine; ordering information, and a copy of an early manuscript for it, can be found at http://linker.iecc.com/ and http://www.iecc.com/linker/ . HTH.
The real point is that the opcodes are what the CPU runs directly; there's no further software interpretation (unless you count the firmaware as an interpreter). The 'interpreter' for opcodes is in the hardware itself.
However, as I pointed out on the Mega-Tokyo site (where Jack asked the same question), what he really seems to be asking about is the procedure for loading an executable file. While this usually involves a certain amount of run-time patching of address information for most relocatable program formats, in principle it could be as simple as copying the file into a specific area of memory and jumping to it. THat is exactly what DOS does with .com files.
This can be a pretty complicated issue, actually. The best book I know of on it is _Linkers and Loaders_ by John Levine; ordering information, and a copy of an early manuscript for it, can be found at http://linker.iecc.com/ and http://www.iecc.com/linker/ . HTH.
-
carbonBased
RE:running a program
Excuse me?
I didn't say opcodes were the asm keywords, I said they were the binary equivalent of them. What's your problem with that?
Every assembly language keyword/operand combination has a corresponding opcode. As Schol-R-LEA pointed out, some instructions have more than one opcode simply because of the different register/memory operand combinations. Perhaps I should've spelt that out myself, as well... I figured it was assumed. Schol-R-LEA knew what I was talking about, as I'm sure most everybody else did, as well... and btw, how are you going to argue against a binary executable as an array of opcodes?
Jeff
PS: I was a computer science major myself... through high school, college _and_ university. Don't assume my education!
I didn't say opcodes were the asm keywords, I said they were the binary equivalent of them. What's your problem with that?
Every assembly language keyword/operand combination has a corresponding opcode. As Schol-R-LEA pointed out, some instructions have more than one opcode simply because of the different register/memory operand combinations. Perhaps I should've spelt that out myself, as well... I figured it was assumed. Schol-R-LEA knew what I was talking about, as I'm sure most everybody else did, as well... and btw, how are you going to argue against a binary executable as an array of opcodes?
Jeff
PS: I was a computer science major myself... through high school, college _and_ university. Don't assume my education!