If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
How many x86 instructions?
On 2/23/2014 4:41 PM, charlie wrote:
The front panel on many of the old mainframes and minicomputers allowed direct entry of machine code, and was usually used to manually enter such things as a "bootstrap", or loader program. The way I recall is any computer only understands machine code and nothing else. Anything else must be converted to machine at some point. -- Bill Gateway M465e ('06 era) - Thunderbird v24.3.0 Centrino Core2 Duo T7400 2.16 GHz - 4GB - Windows 8 Pro w/Media Center |
#22
|
|||
|
|||
How many x86 instructions?
On 2/23/2014, J. P. Gilliver (John) posted:
In message , charlie writes: [] At the time, the only out we had in order to meet contract requirements was to write a combination of assembly code, compiled code, and horrors, machine code. If that wasn't bad enough, we then had to "disassemble" the machine code to see if there was a way to duplicate it at the highest level possible, without writing compiler extensions. What's machine code (as opposed to assembly code) in this context? How did you write it? This might help: When I owned an Apple ][, for a long time I din't own an assembler program. I wrote some code in hex... Let me tell you, "a small change" was a complete oxymoron. "Machine code" means the actual bits or bytes that go into memory. "Assembly code" is a *symbolic* language. Assembly language code, for various reasons, might not even be a perfect 1 to 1 match to what goes into the machine. -- Gene E. Bloch (Stumbling Bloch) |
#23
|
|||
|
|||
How many x86 instructions?
On 2/23/2014 5:45 PM, Gene E. Bloch wrote:
On 2/23/2014, J. P. Gilliver (John) posted: In message , charlie writes: [] At the time, the only out we had in order to meet contract requirements was to write a combination of assembly code, compiled code, and horrors, machine code. If that wasn't bad enough, we then had to "disassemble" the machine code to see if there was a way to duplicate it at the highest level possible, without writing compiler extensions. What's machine code (as opposed to assembly code) in this context? How did you write it? This might help: When I owned an Apple ][, for a long time I din't own an assembler program. I wrote some code in hex... Let me tell you, "a small change" was a complete oxymoron. "Machine code" means the actual bits or bytes that go into memory. "Assembly code" is a *symbolic* language. Assembly language code, for various reasons, might not even be a perfect 1 to 1 match to what goes into the machine. +1 -- Bill Gateway M465e ('06 era) - Thunderbird v24.3.0 Centrino Core2 Duo T7400 2.16 GHz - 4GB - Windows 8 Pro w/Media Center |
#24
|
|||
|
|||
How many x86 instructions?
On 23/02/2014 6:15 PM, BillW50 wrote:
On 2/23/2014 4:41 PM, charlie wrote: The front panel on many of the old mainframes and minicomputers allowed direct entry of machine code, and was usually used to manually enter such things as a "bootstrap", or loader program. The way I recall is any computer only understands machine code and nothing else. Anything else must be converted to machine at some point. I know what Charlie is talking about. When he talks about directly entering machine code, it means typing in the binary codes directly, even without niceness of an assembler to translate it partially into English readable. This would be entering numbers into memory directly, like 0x2C, 0x01, 0xFB, etc., etc. Yousuf Khan |
#25
|
|||
|
|||
How many x86 instructions?
On Sun, 23 Feb 2014 17:15:24 -0600, BillW50 wrote:
On 2/23/2014 4:41 PM, charlie wrote: The front panel on many of the old mainframes and minicomputers allowed direct entry of machine code, and was usually used to manually enter such things as a "bootstrap", or loader program. The way I recall is any computer only understands machine code and nothing else. Anything else must be converted to machine at some point. That sorta the meaning of the word "machine" in "machine code". ;-) The issue is how the programs are stored, in the mean time. If the machine code is never "seen" in the wild, it's an interpreter. If the machine code is stored somewhere it's either "assembled" or "compiled". The major difference being that an "assembled" program has a 1:1 correspondence to its machine code, a "compiled" program will not. Of course a "macro" assembler confuses this point some. |
#26
|
|||
|
|||
How many x86 instructions?
On Fri, 21 Feb 2014 14:23:01 +0000 (UTC) "Robert Redelmeier"
wrote in article le7ng5$jfq$ Hate to break it to you, but you are behind the times. Compilers are passe' -- "modern" systems use interpreters like JIT Java. How else you you think Android gets Apps to run on the dogs-breakfast of ARM processors out there? It is [nearly] all interpreted Java. So much so that Dell can get 'roid Apps to run on its x86 tablet! (AFAIK, iOS still runs compiled Apps prob'cuz Apple _hatez_ Oracle) -- Robert Compilers are NOT passe' The performance penalty for interpreted languages is a large factor. It's fine in many situations - scripting languages and the like - and the modern processors are fast enough to make the performance hit tolerable. Large-scale applications are still compiled and heavily optimized. Time is money. |
#27
|
|||
|
|||
How many x86 instructions?
machine code is stored somewhere it's either "assembled" or
"compiled". There's more! A "Loader" can take a binary type file and add it to memory. If the loader has a system level "map" of memory usage, and resident code entries and exits, it can load the code at a relative or absolute memory location, and inform the system level software where it is. Or it might do a "load and go" so that when the loader is finished, the processor goes to and starts executing at an address provided by the loader. A system might tell the loader where in memory to put the code. A programmer's nightmare is intermixed code and data, with self modifying code added, just for giggles! Some compilers/assemblers used to generate machine code had/have detectable signatures tracing back to the particular development software that was used. This allowed authors to check to see if they were being properly paid for use of their development software. (Freeware or student development software, pay for commercial use) I'd suggest that you don't consider use of "student" or "educational" development software to develop a commercial program! On 2/23/2014 7:34 PM, wrote: On Sun, 23 Feb 2014 17:15:24 -0600, BillW50 wrote: On 2/23/2014 4:41 PM, charlie wrote: The front panel on many of the old mainframes and minicomputers allowed direct entry of machine code, and was usually used to manually enter such things as a "bootstrap", or loader program. The way I recall is any computer only understands machine code and nothing else. Anything else must be converted to machine at some point. That sorta the meaning of the word "machine" in "machine code". ;-) The issue is how the programs are stored, in the mean time. If the machine code is never "seen" in the wild, it's an interpreter. If the machine code is stored somewhere it's either "assembled" or "compiled". The major difference being that an "assembled" program has a 1:1 correspondence to its machine code, a "compiled" program will not. Of course a "macro" assembler confuses this point some. |
#28
|
|||
|
|||
How many x86 instructions?
On Sun, 23 Feb 2014 23:21:52 -0500, Jason
wrote: On Fri, 21 Feb 2014 14:23:01 +0000 (UTC) "Robert Redelmeier" wrote in article le7ng5$jfq$ Hate to break it to you, but you are behind the times. Compilers are passe' -- "modern" systems use interpreters like JIT Java. How else you you think Android gets Apps to run on the dogs-breakfast of ARM processors out there? It is [nearly] all interpreted Java. So much so that Dell can get 'roid Apps to run on its x86 tablet! (AFAIK, iOS still runs compiled Apps prob'cuz Apple _hatez_ Oracle) -- Robert Compilers are NOT passe' The performance penalty for interpreted languages is a large factor. It's fine in many situations - scripting languages and the like - and the modern processors are fast enough to make the performance hit tolerable. Large-scale applications are still compiled and heavily optimized. Time is money. Time may be money but transistors are free. ;-) |
#29
|
|||
|
|||
How many x86 instructions?
On Mon, 24 Feb 2014 13:02:02 -0500 " wrote
in article On Sun, 23 Feb 2014 23:21:52 -0500, Jason wrote: On Fri, 21 Feb 2014 14:23:01 +0000 (UTC) "Robert Redelmeier" wrote in article le7ng5$jfq$ Hate to break it to you, but you are behind the times. Compilers are passe' -- "modern" systems use interpreters like JIT Java. How else you you think Android gets Apps to run on the dogs-breakfast of ARM processors out there? It is [nearly] all interpreted Java. So much so that Dell can get 'roid Apps to run on its x86 tablet! (AFAIK, iOS still runs compiled Apps prob'cuz Apple _hatez_ Oracle) -- Robert Compilers are NOT passe' The performance penalty for interpreted languages is a large factor. It's fine in many situations - scripting languages and the like - and the modern processors are fast enough to make the performance hit tolerable. Large-scale applications are still compiled and heavily optimized. Time is money. Time may be money but transistors are free. ;-) Well, not exactly free. Visit a National Lab sometime to get an idea of the magnitude of the expenditures for "free" transistors. I've been there. Those people do everything to wring out every droplet of performance that they can, even on petaflops machines. |
#30
|
|||
|
|||
How many x86 instructions?
On Mon, 24 Feb 2014 13:38:40 -0500, Jason
wrote: On Mon, 24 Feb 2014 13:02:02 -0500 " wrote in article On Sun, 23 Feb 2014 23:21:52 -0500, Jason wrote: On Fri, 21 Feb 2014 14:23:01 +0000 (UTC) "Robert Redelmeier" wrote in article le7ng5$jfq$ Hate to break it to you, but you are behind the times. Compilers are passe' -- "modern" systems use interpreters like JIT Java. How else you you think Android gets Apps to run on the dogs-breakfast of ARM processors out there? It is [nearly] all interpreted Java. So much so that Dell can get 'roid Apps to run on its x86 tablet! (AFAIK, iOS still runs compiled Apps prob'cuz Apple _hatez_ Oracle) -- Robert Compilers are NOT passe' The performance penalty for interpreted languages is a large factor. It's fine in many situations - scripting languages and the like - and the modern processors are fast enough to make the performance hit tolerable. Large-scale applications are still compiled and heavily optimized. Time is money. Time may be money but transistors are free. ;-) Well, not exactly free. Visit a National Lab sometime to get an idea of the magnitude of the expenditures for "free" transistors. I've been there. Those people do everything to wring out every droplet of performance that they can, even on petaflops machines. Now, divide that expenditure by the number manufactured. I worked in high-end microprocessor design for seven or eight years. Transistors are indeed treated as free, and getting cheaper every year. If you look at how programmers write, they think they're free, too. ;-) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
refill instructions for hp 4v | panxerox | Printers | 0 | February 18th 07 07:25 PM |
Instructions SSE | bruno | Overclocking AMD Processors | 1 | May 10th 06 05:10 AM |
Instructions - terrible | Travis King | AMD x86-64 Processors | 3 | January 8th 05 03:04 PM |
REP instructions and TLB caching | John Marcus | Intel | 1 | October 22nd 04 06:23 PM |