[msuper69]

Originally Posted by Detrius

I acknowledge that what you original said was misinterpreted, but I do have to say that assembly language isn't a higher level language than machine code. In mathematical terms, there is a 1-to-1 and "onto" mapping between the two languages. The conversion is invertible. Basically, the machine language is the same thing as the assembly language. The difference is that the machine understands the binary version, and the human understands the hexadecimal and english versions. Claiming that assembly code isn't machine code is like claiming that C code isn't C++ code. At some level, you can make the claim, but at the same time you can't...

Assembly language is one level up from machine language.

If we had to write in machine code, we would write instructions such as 0010 0000 0001 0011 1100 1111 0000.

Assembly language let's use write using mneumonics such as JMP EXIT in place of a string of 0s and 1s.

Note that the examples I've used are not to be taken literally. They won't assemble; they're just for showing the difference between machine language and assembly language.

[Chuckit]

Originally Posted by msuper69

Assembly language is one level up from machine language.

If we had to write in machine code, we would write instructions such as 0010 0000 0001 0011 1100 1111 0000.

Assembly language let's use write using mneumonics such as JMP EXIT in place of a string of 0s and 1s.

So if I came up with a language with the same syntax and constructs as C, except the standard library used vowels in its function names, that would be a higher-level language? No. It would be a language on the same level with more readable function names. (Also, I'm not sure whether you realize this, but the string "JMP EXIT" is represented by ones and zeroes just like machine code — it's just a different string of ones and zeroes that text editors can interpret as characters.)

[Chuckit]

Originally Posted by Tsilou B.

If someone (let's say a hard drive manufacturer) redefines these terms (GiB, MiB, KiB) to be metric even though they could simply use the existing metric terms (GB, MB, KB etc.), then you can sue the hell out of them, because that wouldn't be mere simplification, but malicious deceit. Gi, Mi and Ki are never, not in a single case, metric - quite contrary to G,M,K.

The terms "kilobyte," "megabyte" and "gigabyte" were never metric either until drive manufacturers started misusing them. Just because they happen to sound similar to other words that are metric doesn't mean they were any more than "kibibyte" and its awful-sounding brothers.

[msuper69]

Originally Posted by Chuckit

So if I came up with a language with the same syntax and constructs as C, except the standard library used vowels in its function names, that would be a higher-level language? No. It would be a language on the same level with more readable function names. (Also, I'm not sure whether you realize this, but the string "JMP EXIT" is represented by ones and zeroes just like machine code — it's just a different string of ones and zeroes that text editors can interpret as characters.)

JMP EXIT is assembled into machine language. Of course I know it's represented by a string of 1s and 0s. Everthing is 1s and 0s to the CPU. It' how we humans write the code.

[Tsilou B.]

Originally Posted by Chuckit

The terms "kilobyte," "megabyte" and "gigabyte" were never metric either until drive manufacturers started misusing them. Just because they happen to sound similar to other words that are metric doesn't mean they were any more than "kibibyte" and its awful-sounding brothers.

I know that. But the fact remains: The hard drive manufacturers could only "misuse" the names without having to fear lawsuits, because K,M and G mean 1000, 1,000,000 and 1,000,000,000 in EVERY OTHER definition. That's why a few years ago the definition of KB, MB and GB was changed, so now people who say 1KB=1024 bytes are the ones who don't abide by the definition.
"kibibyte" sounds awful and I have no idea why the IEC chose that totally stupid name, but nevertheless, it solves the problem: No hard disk manufacturer could ever dare to offer a hard drive that holds 1,000,000,000,000 bytes (1TB by the the new definition) as a 1TiB hard drive.

[Chuckit]

Originally Posted by Tsilou B.

I know that. But the fact remains: The hard drive manufacturers could only "misuse" the names without having to fear lawsuits, because K,M and G mean 1000, 1,000,000 and 1,000,000,000 in EVERY OTHER definition. That's why a few years ago the definition of KB, MB and GB was changed, so now people who say 1KB=1024 bytes are the ones who don't abide by the definition.
"kibibyte" sounds awful and I have no idea why the IEC chose that totally stupid name, but nevertheless, it solves the problem: No hard disk manufacturer could ever dare to offer a hard drive that holds 1,000,000,000,000 bytes (1TB by the the new definition) as a 1TiB hard drive.

Why not? If the IEC will just change the definition of a word and come up with an even stupider one to hold the old meaning whenever hard drive manufacturers start raping the old term, how are we going to sue them? By the time anyone gets around to it, we'll have to be counting our hard drive space in kilifloozlebytes (KfZlB).

I think we could have sued them before, but nobody bothered. Now there's a large number of geeks who want to roll over and let them have the real term, so we're too divided to sue.

[Person Man]

Originally Posted by Chuckit

Why not? If the IEC will just change the definition of a word and come up with an even stupider one to hold the old meaning whenever hard drive manufacturers start raping the old term, how are we going to sue them? By the time anyone gets around to it, we'll have to be counting our hard drive space in kilifloozlebytes (KfZlB).

I think we could have sued them before, but nobody bothered. Now there's a large number of geeks who want to roll over and let them have the real term, so we're too divided to sue.

Let's work on getting memory to be sold using KiB, MiB, etc. first, then...

People talk about 1 GB memory (1 GB = 1024 MB = 1024 KB, by the base 2 definition)

Until then, we've got problems.

And someone HAS brought a class action lawsuit against the drive manufacturers (and several computer companies, including Apple).

[Hugi]

Now it's just a matter of time until a Mars mission fails because NASA used Kibibytes and Lockheed Martin used Kilobytes.

[Boondoggle]

Well I'm glad that is settled, now I can go back to worrying about silly things again.

[Tsilou B.]

Originally Posted by Chuckit

Why not? If the IEC will just change the definition of a word and come up with an even stupider one to hold the old meaning whenever hard drive manufacturers start raping the old term, how are we going to sue them?

I'm not sure why you don't get it. I guess it's because in the US, you usually don't use a metric system. Here we use only metric terms and we're used to putting K in front of any unit if we mean 1000. We have g (gramms) for measuring weight and everyone knows that 1 kg must be exactly 1000g. We have m (meters) for measuring length and of course, 1 km must be exactly 1000m. Frequencies are measured in Hz and if you see a frequency of 1KHz you do NOT have to look in some book to find out if 1KHz means 997.829Hz or 1056Hz, no, you can be totally sure that 1KHz is exactly 1000Hz. It's the same with EVERY OTHER unit. It was not really logical to have 1 KB = 1024 bytes. It was the ONLY exception to the rule. Now along came the hard drive manufacturers and used the usual meaning of 1K = 1000.
In contrast, the prefix Ki ALWAYS means 1024. When the hard drive manufacturers "rape" that term, we will sue them, they will not be able to make excuses, and the IEC will certainly not change the meaning of Ki. They have never changed the meaning of any prefix, they have only eliminated the only exception to the rule that K means 1000 - exactly 1000, neither 1024 nor 998.362.

[mactropolis]

Originally Posted by Tsilou B.

I'm not sure why you don't get it. I guess it's because in the US, you usually don't use a metric system. Here we use only metric terms and we're used to putting K in front of any unit if we mean 1000. We have g (gramms) for measuring weight and everyone knows that 1 kg must be exactly 1000g. We have m (meters) for measuring length and of course, 1 km must be exactly 1000m. Frequencies are measured in Hz and if you see a frequency of 1KHz you do NOT have to look in some book to find out if 1KHz means 997.829Hz or 1056Hz, no, you can be totally sure that 1KHz is exactly 1000Hz. It's the same with EVERY OTHER unit. It was not really logical to have 1 KB = 1024 bytes. It was the ONLY exception to the rule. Now along came the hard drive manufacturers and used the usual meaning of 1K = 1000.
In contrast, the prefix Ki ALWAYS means 1024. When the hard drive manufacturers "rape" that term, we will sue them, they will not be able to make excuses, and the IEC will certainly not change the meaning of Ki. They have never changed the meaning of any prefix, they have only eliminated the only exception to the rule that K means 1000 - exactly 1000, neither 1024 nor 998.362.

Exactly.

We lost the battle on reclaiming KiloByte, MegaByte and GigaByte to mean binary (thanks to HD manufactures insistance on mislabeling their drives). Let KB, MB, and GB describe metric byte units and the new system (KiB, MiB & GiB) exclusively for binary byte units. Hard dick companies can continue to advertise their products as GB, however the OS will report it in GiB. Problem solved. Why's that so hard to understand?

[ghporter]

What's hard to understand about just knowing hard drive manufacturers will refer to decimal numbers (for marketing purposes) and everyone else will use binary-based numbers? I really don't see a need for a massive, industry-wide change just because of that.

OS makers SHOULD be enforcing consistency in how file sizes and free space are reported throughout the OS and utilities. Whatever you use to look at a file and disk usage should show you the same answer. That is strictly a user interface issue, and one that can easily be solved by some simple management work on Apple's part-designating a standard for how MacOS software should talk to the user is in this regard isn't rocket science.

[Chuckit]

Originally Posted by Tsilou B.

I'm not sure why you don't get it. I guess it's because in the US, you usually don't use a metric system. Here we use only metric terms and we're used to putting K in front of any unit if we mean 1000. We have g (gramms) for measuring weight and everyone knows that 1 kg must be exactly 1000g. We have m (meters) for measuring length and of course, 1 km must be exactly 1000m.

I do understand that. But that is not what these terms meant, and anyone who thought so is even more foolish than someone who would light a match in a room filled with "inflammable" gas because that must be safe. Regardless of what other terms mean, these did not mean that. You may as well say "Mi" could be confusing because it sounds like a musical note, and maybe Europeans are going to think you can only store songs with that note on the hard drive. If people can't understand that words aren't defined by "Well, gee, it has the same sound as in this other word," they shouldn't be involved in decision-making.

More to the point, "KB" still generally means "1024 bytes" to a lot more people than "KiB" does, so it's still a better term for that, and people who encourage the use of a neologism are just encouraging confusion.

[Tsilou B.]

Originally Posted by Chuckit

I do understand that. But that is not what these terms meant [...] Regardless of what other terms mean, these did not mean that.

That's certainly correct.

Originally Posted by Chuckit

You may as well say "Mi" could be confusing because it sounds like a musical note, and maybe Europeans are going to think you can only store songs with that note on the hard drive.

This is the most ridiculous comparison I've ever seen.

Originally Posted by Chuckit

If people can't understand that words aren't defined by "Well, gee, it has the same sound as in this other word," they shouldn't be involved in decision-making.

The prefix "kilo" itself has the meaning 1000 in the "Système International d'Unités".

Originally Posted by Chuckit

More to the point, "KB" still generally means "1024 bytes" to a lot more people than "KiB" does, so it's still a better term for that, and people who encourage the use of a neologism are just encouraging confusion.

No, people who still use 1KB=1024 bytes are encouraging confusion, because:

Originally Posted by mactropolis

We lost the battle on reclaiming KiloByte, MegaByte and GigaByte to mean binary (thanks to HD manufactures insistance on mislabeling their drives). Let KB, MB, and GB describe metric byte units and the new system (KiB, MiB & GiB) exclusively for binary byte units. Hard disk companies can continue to advertise their products as GB, however the OS will report it in GiB. Problem solved. Why's that so hard to understand?

[P]

Originally Posted by mactropolis

Exactly.

We lost the battle on reclaiming KiloByte, MegaByte and GigaByte to mean binary (thanks to HD manufactures insistance on mislabeling their drives). Let KB, MB, and GB describe metric byte units and the new system (KiB, MiB & GiB) exclusively for binary byte units. Hard dick companies can continue to advertise their products as GB, however the OS will report it in GiB. Problem solved. Why's that so hard to understand?

It's not hard to understand. It's morally wrong to let the lying marketting departments win.

[Tsilou B.]

Originally Posted by P

It's not hard to understand. It's morally wrong to let the lying marketting departments win.

I must admit that's a really good reason to protest against kibibytes.
Still I think that unless we could stop the HD manufacturers from using their new definitions (and we won't be able to do that because of the redefinition by the IEC), we would be better off with the new units. Why did they have to give them these silly names

[Chuckit]

Originally Posted by Tsilou B.

The prefix "kilo" itself has the meaning 1000 in the "Système International d'Unités". Look here if you don't believe that:

http://en.wikipedia.org/wiki/Kilo

And the prefix "in-" means "not." Are you going to light a match in a room filled with inflammable gas? I certainly hope not.

Originally Posted by Tsilou B.

No, people who still use 1KB=1024 bytes are encouraging confusion, because:

Because you and mactropolis want to let hard drive manufacturers dictate your language to you?

There is no reason to have a word meaning "1000 bytes" aside from making your hard drive sound bigger by co-opting a term that actually means "1024 bytes." It's a meaningless amount. I am not giving the hard drive manufacturers a perfectly good word to reward them for false advertising. If "KiB" came to be the common term for measuring drive space, no doubt HD makers would steal that one too but continue to number them as they do now, and it would really be no more deceptive, since the meaning of both was equally well-understood before they came along.

[Hugi]

In a couple of years this entire discussion will be forgotten. "Kilo" will have regained it's purity as a prefix meaning "times one thousand" (alond with it's Mega, Giga, Tera etc. siblings) and the new system of "kibi", "mebi", "gibi" etc. will become the universal standard for binary prefixing, which is a completely different thing.
Most people should be able to go through life without having to know the difference between the binary and decimal systems. Even if they use computers. This whole "kilobyte" thing was just silly.

I don't see why we should be afraid of a tiny change that's for the better.

[Maneki Neko]

Originally Posted by Tsilou B.

That's not the point. No one wants to use a metric system when it's absolutely stupid to do so. But it makes sense to use another nomenclature (TiB, GiB, MiB, KiB) instead of using the metric terms for things that are not metric, especially if things get worse all the time (KiB/KB = 102,4% - almost negligible, but soon TiB/TB = 110,0% - 10% difference!).

Outside of kilo though, I really haven't heard the other metric prefixes applied to units in general usage.

Terameters? Gigagrams? Megaliters? I realize they're defined, but still.....

[ghporter]

Originally Posted by Maneki Neko

Outside of kilo though, I really haven't heard the other metric prefixes applied to units in general usage.

Terameters? Gigagrams? Megaliters? I realize they're defined, but still.....

Those other units are not typically used in daily life, but in some specialized areas they're used all the time. Freight is still mainly defined in terms of the ton, but it's now the "tonne" or "metric ton" which is amazingly close to the old "long ton." A "short ton" is supposed to be exactly 2000 pounds, while a long ton is 2,240 pounds, which is 1,016.05 kilos or 1.016 metric tons. You see, there's a LOT of nomenclature that's not in normal daily usage that has particularly important usage in specialized areas.

[Hugi]

Originally Posted by ghporter

Those other units are not typically used in daily life, but in some specialized areas they're used all the time. Freight is still mainly defined in terms of the ton, but it's now the "tonne" or "metric ton" which is amazingly close to the old "long ton." A "short ton" is supposed to be exactly 2000 pounds, while a long ton is 2,240 pounds, which is 1,016.05 kilos or 1.016 metric tons. You see, there's a LOT of nomenclature that's not in normal daily usage that has particularly important usage in specialized areas.

A metric ton is exactly 1.000 kilograms, and that's what used by every industry in Europe. Don't mix that endlessly confusing pound-stuff into this.

To me, the argument against kibibytes sounds like this "we've had it wrong for twenty years, why make it right when we can keep it wrong to confuse everyone who isn't into computers"?

There's even a question in Trivial Pursuit that asks "how many bytes are in a kilobyte". It's obviously a trick question and almost everyone I've played that game with always says "one thousand". Why? Because it's the right answer. A kilobyte _is_ one thousand bytes.

It's about as sensible to redefine the prefix "kilo" just for computers as it would be for the US to redefine the volume of a "gallon" just for diesel powered cars. It's just silly.

[Hugi]

Originally Posted by Maneki Neko

Outside of kilo though, I really haven't heard the other metric prefixes applied to units in general usage.

Sure you have. Nano, micro, milli, centi, deci. they're all "metric prefixes".

[khufuu]

KB, MB, and GB have absolutely NOTHING to do with metric. Stop it! Yes they are prefixes borrowed from metric just because people knew about them but, No they are not metric.

As only one person above has said, the K stands for 'roughly' 1000 bytes. Computer nerds always found ways to shorten things so K was adopted to represent 1024 just because it was one letter that was 'close enough'. All computer people who programmed in assembler knew this. It in no way, shape, or form did K represent 1000 bytes. Ever.

And, by the way, assembler IS a higher level language than machine code. If you HAVE to compile a language, which assembler is one, it's NOT machine code.

In the old days, as someone mentioned above about the PDP-10/11 series of computers by DEC, you had to power 'on' the machine and then 'toggle' in the bootstrap by the use of a series of switches to actually represented the 1's and 0's required to 'boot' the computer up. No bios here folks. You actually keyed in binary to boot the machine enough so that the operating system could kick in and take care of the rest.

/rant

[mactropolis]

Originally Posted by ghporter

What's hard to understand about just knowing hard drive manufacturers will refer to decimal numbers (for marketing purposes) and everyone else will use binary-based numbers? I really don't see a need for a massive, industry-wide change just because of that.

What's the point of this massive, industry-wide shift? The point is that it will benefit *users*. Its the user who benefit because when they buy a 60 GB iPod and then get disappointed thats you only get 55.7GB capacity reported by the OS. Or when Joe Sixpack buys a 250 GB hard disk and shockingly gets 232 GB of actual capacity. Every part of the globe consumers find this deceitful, aggravating, and duplicitous. This solves it by using a new nomenclature system.

You see ghporter, for you and I geeks we automatically know that HD makers will advertise in metric byte units, which are not the same as binary byte units. Now try explaining this concept to every Joe Sixpack who buys a hard drive, iPod, laptop, desktop, flash drive, or anything else that has a hard disk. Lets not forget this same problems also applies to blank optical DVD media as well (advertised as "4.7 GB", only get 4.37 GiB). Thats the problem. By clearly using KiB, MiB, GiB in the OS to label sizes, it solves that. Just because we here know the difference between binary byte units and metric byte units, you'd be incredibly wrong to assume Joe Sixpack understands as well. Get it?

[Chuckit]

Originally Posted by khufuu

And, by the way, assembler IS a higher level language than machine code. If you HAVE to compile a language, which assembler is one, it's NOT machine code.

It isn't machine code, but commands in assembler have a 1:1 correspondence with commands in machine code. Therefore, it is not higher level. It just just a human-readable language on the same level.

[msuper69]

Originally Posted by Chuckit

It isn't machine code, but commands in assembler have a 1:1 correspondence with commands in machine code. Therefore, it is not higher level. It just just a human-readable language on the same level.

Sorry, but assembly statements must first be assembled to generate machine code. It's not a 1:1 correspondence. If that were true, then you could just code assembly language and run it w/o running it through an assembler first. With machine code, it will run w/o any further processing by an assembler/compiler/linker. Of course, I certainly wouldn't want to have to go through that kind of precision coding. Assembly language is what makes it a heck of a lot easier to program. You try it sometime. Write the same program first in machine code. Then write it using assembly code. Still think it's the same level?

[ghporter]

Originally Posted by mactropolis

What's the point of this massive, industry-wide shift? The point is that it will benefit *users*. Its the user who benefit because when they buy a 60 GB iPod and then get disappointed thats you only get 55.7GB capacity reported by the OS. Or when Joe Sixpack buys a 250 GB hard disk and shockingly gets 232 GB of actual capacity. Every part of the globe consumers find this deceitful, aggravating, and duplicitous. This solves it by using a new nomenclature system.

You see ghporter, for you and I geeks we automatically know that HD makers will advertise in metric byte units, which are not the same as binary byte units. Now try explaining this concept to every Joe Sixpack who buys a hard drive, iPod, laptop, desktop, flash drive, or anything else that has a hard disk. Lets not forget this same problems also applies to blank optical DVD media as well (advertised as "4.7 GB", only get 4.37 GiB). Thats the problem. By clearly using KiB, MiB, GiB in the OS to label sizes, it solves that. Just because we here know the difference between binary byte units and metric byte units, you'd be incredibly wrong to assume Joe Sixpack understands as well. Get it?

This really is a different issue. FORMATTED capacity loss is a lot more significant than the difference between reporting size in decimal versus binary. Just try explaining that to a non-computer person...it ain't easy for me, and I'm a trained instructor.

Edited to fix stupid quote trick.

[mactropolis]

Originally Posted by ghporter

This really is a different issue. FORMATTED capacity loss is a lot more significant than the difference between reporting size in decimal versus binary. Just try explaining that to a non-computer person...it ain't easy for me, and I'm a trained instructor.

Huh?? Where did "formatted capacity loss" come from?! I think we're all aware that every storage media needs essential drivers to make it usable, even optical. All discussions in this topic do not involve anything to do with amount of space before vs. after performing a format. That's an entirely other topic, which obviously depends on the file system of choice. Besides todays modern file systems handle large capacity drives very well, maximizing use and efficiency. Also, there's no need to explain to a person the benefit of formatting -- it has to be done to make the device usable, period. Any any such space needed to store file system metadata is usually extremely negligible. On the other hand, the space difference between metric vs binary bytes will be even more enormous in years to come (36 GB 'missing' for a "500 GB" HD)

[ghporter]

Originally Posted by mactropolis

Huh?? Where did "formatted capacity loss" come from?! I think we're all aware that every storage media needs essential drivers to make it usable, even optical. All discussions in this topic do not involve anything to do with amount of space before vs. after performing a format. That's an entirely other topic, which obviously depends on the file system of choice. Besides todays modern file systems handle large capacity drives very well, maximizing use and efficiency. Also, there's no need to explain to a person the benefit of formatting -- it has to be done to make the device usable, period. Any any such space needed to store file system metadata is usually extremely negligible. On the other hand, the space difference between metric vs binary bytes will be even more enormous in years to come (36 GB 'missing' for a "500 GB" HD)

I have to admit that I never calculated the difference between binary and decimal sizes for such a large drive. But this is still relevant-if a user buys a "120GB" drive, he or she should be aware that the number on the box is RAW SPACE, and that formatted space will be substantially smaller. And until you get up to really, REALLY big drives, I think the binary/formatted size differential is still significant-a "120 billion-byte" drive will be 8,849,018,880 bytes smaller than a "120 gigabyte" drive, while formatting in some file systems will take up to 10% of the raw drive space (NTFS takes over 12% for the Master File Table!), and default cluster sizes can steal a lot more as "slack" space.

However, I've just been reminded of another issue that makes the "let's force the drive manufacturers to do it this way" question muddier. By convention, hard drive data transfer rates are presented in decimal format-the various Ultra ATA modes are ALL represented by decimal numbers, not binary numbers. Since these data rates are so thouroughly embedded in the drive industry, the whole binary/decimal thing doesn't seem to be such a cut-and-dried issue now.

[Anubis IV]

But doesn't basically every other industry rely on the binary way of things? RAM, video cards, etc? Why should the hard drive manufacturers be allowed to get away with something that other industries aren't allowed to do? I don't think that kibi should be used...rather, I do think that the name should be reclaimed and brought back in line with its original meaning.

[mactropolis]

Originally Posted by Anubis IV

But doesn't basically every other industry rely on the binary way of things? RAM, video cards, etc? Why should the hard drive manufacturers be allowed to get away with something that other industries aren't allowed to do? I don't think that kibi should be used...rather, I do think that the name should be reclaimed and brought back in line with its original meaning.

But the original meaning of 'kilo' always meant 1,000 not 1024. True, it may rub some people as being 'wrong' to let the hard drive manufactures get away with it, but recall that numerous lawsuits spanning decades all over the world have failed to force hard drive makers to properly label their drives for the intended use (computers). Also realize that in every other industry besides the computer industry (and its sub-industries: RAM, video cards, etc), the proper definition for kilo, mega, & giga is used (1000, 1M, 1B respectively). Ideally HD makers would print "250 GB" on the box for a 250 GB (binary/base2) HD. But I think we'll see cows flying over the moon before that happens. Feel free to launch your crusade however. Best luck (you'll need it). In the mean time, this new naming system is the easiest fix.

[Chuckit]

Originally Posted by msuper69

Sorry, but assembly statements must first be assembled to generate machine code. It's not a 1:1 correspondence. If that were true, then you could just code assembly language and run it w/o running it through an assembler first.

No, that would be if they were the same. 1:1 correspondence means that every command in assembler has a direct equivalent in machine code and vice-versa. By the same token, rot-13 coded text has a 1:1 correspondence with the source language, but it is not readable by someone who only knows the source language.

Originally Posted by msuper69

Write the same program first in machine code. Then write it using assembly code. Still think it's the same level?

The term "high-level" generally means "with a greater degree of abstraction." I don't see how this is supposed to prove that assembly is more abstract than machine code. You're just proving what I said — it's a language on the same level that uses a more understandable lexicon for humans.

[Detrius]

Originally Posted by msuper69

Sorry, but assembly statements must first be assembled to generate machine code. It's not a 1:1 correspondence. If that were true, then you could just code assembly language and run it w/o running it through an assembler first. With machine code, it will run w/o any further processing by an assembler/compiler/linker. Of course, I certainly wouldn't want to have to go through that kind of precision coding. Assembly language is what makes it a heck of a lot easier to program. You try it sometime. Write the same program first in machine code. Then write it using assembly code. Still think it's the same level?

You are effectively making the argument that binary, decimal, and hexadecimal are on different levels. Show me a number that exists in decimal that doesn't in binary and you might have grounds to stand on. LIkewise, show me an assembly command that doesn't translate into a single machine language command ( and vice versa ) and then you have grounds to stand on.

C is on a different level because its definition is not dependent on the implementation of the processor. Just because you can write a "for" loop in C doesn't mean that there is a command on the processor that has an even remotely similar function.

Machine code and assembly are the same thing in the sense that binary and hexadecimal are the same thing. Obviously, they look different, but four binary characters translate directly into one hexadecimal character. DEAF is 1101 1110 1010 1111. This is how simple the conversion from machine code to assembly is--it's simpler than the conversion from hexadecimal to decimal.


BTW, I have written programs from scratch in assembly... granted, it was on a 286, but it's the same idea.

[khufuu]

Originally Posted by Chuckit

No, that would be if they were the same. 1:1 correspondence means that every command in assembler has a direct equivalent in machine code and vice-versa. By the same token, rot-13 coded text has a 1:1 correspondence with the source language, but it is not readable by someone who only knows the source language.


The term "high-level" generally means "with a greater degree of abstraction." I don't see how this is supposed to prove that assembly is more abstract than machine code. You're just proving what I said — it's a language on the same level that uses a more understandable lexicon for humans.

As my example several posts ago. I used to boot the server by keying in binary machine language from toggle switches on the front of the machine. This was how you loaded machine language directly into a specific chunk of RAM on the server. Once it was all entered in, you hit another switch that told the system to run the program directly from that memory space.

Now. Assembler is keyed into a file. It's just text sitting in a file that's far more readable to humans than to computers. Why? Because you must 'run' a program against that file to turn it into something the computer can actually understand. ... 'with a greater degree of abstraction.' was the exact phase I believe. MOV R1,R2 might have a 1:1 correspondence with machine code but it is still a higher level of abstraction because it's still just text sitting in a file

Sorry folks... back to the regularly scheduled program