Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
We were having a discussion in #cemetech over the idea of using hex digits to write code and using mnemonics to write your code. What are your views on this?
My opinion, from the discussion, is that, provided a representation contains no more information than another, the two are equivalent.
Therefore, state of units in RAM/ROM == binary == hex == disasm-style ASM
calcdude84se wrote:
My opinion, from the discussion, is that, provided a representation contains no more information than another, the two are equivalent.
Therefore, state of units in RAM/ROM == binary == hex == disasm-style ASM


Same here.
I disagree with calcdude. The mnemonics are there to help. They have the same code. And they save space. My problem with them was the whole push pop thing. Hex is not AS FAST as binary. It must be translated in the compiler to binary anyway. The z80 cannot parse hex, only highs and lows of current. There cannot be 16 shades of current. Thats not how a transistor works.
Hex==form of binary yes, but binary==faster version of hex.
Hex is good only for expressing binary in shorter terms. Nobody wants to type out the whole 1000110100 when you can type 234 and get the same number. Saves the planet when you think about it!
If you have an assembler then writing machine code by hand is a waste of time. It's still useful to know how assembly mnemonics translate into machine code for the sake of optimisation and tricks like self-modifying code, but having to commit the opcode values to memory (or continuously consult a reference) and count out addresses by hand is a slow and unmaintainable endeavour.
The message being communicated to the machine, in the absence of all other things, is the same, regardless of what form you're using, be it hex digits or mnemonics. Both are translated into machine code which are then executed by the machine, so in either representation, it makes no difference.

On the other hand, if you include the human element into the equation, I'd stick with the mnemonics. It makes it easier for the "rest of us" to read and therefore learn from and make changes. I think of this concept similar to trying to represent a statement in English by writing your alphanumeric characters 0-9,A-Z,a-z. What if you wrote that out in hex digits? Sure, the person reading that statement can derive the same content from both forms, but the underlying idea, the words that form the language, remain untouched, and therefore, constant. If all people were taught to read hex and understand that for what we'd call letters, expressing ideas to one another would be no different other than the representation used to express it. </rambling>

Erh... anyway. I'm a normie. I'd prefer mnemonics tyvm. Easier to express myself to the machine that way.
I call hex a number representation format, not a programming language. I consider people who call ASM hex to be making an error.
I seem to have gotten off the central topic to a more philosophical bent. Heh.
Edit: Just to say it, note how I said disasm-style ASM.
God Iambian. Never knew you had it in you. Really humbling. Still I wanna know how the whole thing works. Makes lots of sense of the senselessness I had there a bit ago. The assembler still has to translate the hex, which makes the binary the lowest form of programming, which is where the argument started. ASM is NOT the lowest you can go, just the lowest LANGUAGE you can go. The numbers I must say are not a LANGUAGE but a literal on and off for the machine.
The numbers are a language; the z80 processor makes them be that. And, note that %01100100 = $64 = 100d.
I guess the point I make here is that the processor endows those numbers with meaning Smile
Edit: Part of my point is that these all contain exactly the same amount of information. NOP means as much with respect to the z80 processor as $00 as does 0d, or %00000000
I thought the assembler "endowed these numbers with meaning", not the processor...?
KermMartian wrote:
I call hex a number representation format, not a programming language. I consider people who call ASM hex to be making an error.

If I'm reading that correctly, the only reason I believe people would distinguish between "hex asm" and just "asm" is in fact the way the language is represented, rather than the language itself.

I'm led to believe that when people speak of "asm," we're talking about this mishmash of mnemonics that occupy some plaintext file which is then passed onto some compiler or assembler which converts it to a binary, ready to be read by the machine in question. Saying that something coded in "hex asm" is telling me that instead of mnemonics, they coded it in a representation that a machine could convert into a binary in a manner that is far easier than converting mnemonics to a binary. Useful if you're working on a platform in which you'd prefer the faster and easier method of conversion to a binary. Near-useless if you had something where the ease (or lack of) makes no difference in the generation of a binary. I say "near-useless" because there are educational properties to be had when expressing yourself to the machine in hex.
Take a look at the Z80 CPU user manual for more information about the operation of the CPU, including how the opcodes are formed.
yes, so binary IS the lowest you can get, not ASM! I win! until merth wins first...
Adept: it's the processor that runs the opcodes, is it not?
Also, let's distinguish "binary" and "a binary". Just as a warning. Razz
thx for the zilog documentation. OpCodes is what those are called?? Wow!
Opinion doesn't have a lot to do with this. There can be an opinion on what's easier to read, but not on what's actually "better" as far as the computer is concerned.
Let's say I have an assembler, and this assembler will convert a text file into a program that a computer can run. This assembler can take a text file written with mnemonics, or opcodes represented as hex or binary. Now, let's say that the mnemonic "HELLO" makes the computer print "HELLO. Now, let's say that the opcode is 0b10, which is 0x2. So, you have three text files.
The mnemonic one:

Code:
HELLO

The hex opcode one:

Code:
2

And the binary opcode one:

Code:
10

You run these through the assembler and you get the exact same program. Now, the program will be represented in the computer as some numbers. Those numbers will be the opcodes. Now, if you bust it open in a hex editor, it'll say "2". If you bust it open with a binary editor (I don't think anyone would ever use that), it'll say "10". If you disassemble it, it'll probably tell you "HELLO", since that's the decided mnemonic for it. If you open it in a text file, it'll try to show the ASCII character for 0x2 (which is a start of text thing).
These are all just different ways to represent the same thing, and once you get to the machine level, it doesn't even matter. The machine is just holding numbers, the machine doesn't do anything differently depending on how it was assembled. And, most likely, the compiler isn't any slower or faster if you use hex or binary (with the mnemonic it has to translate it instead of just packing it, so that is a tiny bit slower, but it doesn't really matter).
adept wrote:
I disagree with calcdude. The mnemonics are there to help. They have the same code. And they save space. My problem with them was the whole push pop thing. Hex is not AS FAST as binary. It must be translated in the compiler to binary anyway. The z80 cannot parse hex, only highs and lows of current. There cannot be 16 shades of current. Thats not how a transistor works.
Hex==form of binary yes, but binary==faster version of hex.
Hex is good only for expressing binary in shorter terms. Nobody wants to type out the whole 1000110100 when you can type 234 and get the same number. Saves the planet when you think about it!


In RAM, assembly programs are essentially 1's and 0's, but the OS shows it as hex. There is no "translator" to change hex into binary, hex is binary only in a more condensed format. Binary is not the lowest you can get, actually making the logic gates is the lowest. Binary and ASM are the same thing, just with different names.
merthsoft wrote:
Opinion doesn't have a lot to do with this. There can be an opinion on what's easier to read, but not on what's actually "better" as far as the computer is concerned.
Let's say I have an assembler, and this assembler will convert a text file into a program that a computer can run. This assembler can take a text file written with mnemonics, or opcodes represented as hex or binary. Now, let's say that the mnemonic "HELLO" makes the computer print "HELLO. Now, let's say that the opcode is 0b10, which is 0x2. So, you have three text files.
The mnemonic one:

Code:
HELLO

The hex opcode one:

Code:
2

And the binary opcode one:

Code:
10

You run these through the assembler and you get the exact same program. Now, the program will be represented in the computer as some numbers. Those numbers will be the opcodes. Now, if you bust it open in a hex editor, it'll say "2". If you bust it open with a binary editor (I don't think anyone would ever use that), it'll say "10". If you disassemble it, it'll probably tell you "HELLO", since that's the decided mnemonic for it. If you open it in a text file, it'll try to show the ASCII character for 0x2 (which is a start of text thing).
These are all just different ways to represent the same thing, and once you get to the machine level, it doesn't even matter. The machine is just holding numbers, the machine doesn't do anything differently depending on how it was assembled. And, most likely, the compiler isn't any slower or faster if you use hex or binary (with the mnemonic it has to translate it instead of just packing it, so that is a tiny bit slower, but it doesn't really matter).

Wow. A really expanded version of my opinion Very Happy
Something inside me still wants to disagree, but that something is not reason. Thx Merth for schooling us all in how an assembler works. That's info the future will NEED!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement