OSDev.org

DavidCooper wrote:Here are a few screenshots to show you MSB-OS

So completely wacko that it's insanely cool. The only think I don't understand is why you display the machine code as decimal instead of hex. Or was "the most unintuitive way to display machine code" actually a goal? :)


JAL

David claims that decimal notation allows him to "read" the program flow more easily, and that hex hides information from him.

jal wrote:

DavidCooper wrote:Here are a few screenshots to show you MSB-OS

So completely wacko that it's insanely cool. The only thing I don't understand is why you display the machine code as decimal instead of hex. Or was "the most unintuitive way to display machine code" actually a goal?

JAL

I wrote the earliest version within Basic data statements which happen to use decimal values. Had they used hex, I would have used hex instead, and I might never have discovered the advantages of using decimals. Decimals are better for two reasons:-

Firstly, hex is alien to those of us who grew up using a human language with a base 10 number system: speaking numbers like 8A, 8E and 80 leads to communication difficulties and can even lead to errors when just trying to hold values in your head for a few moments. I'm sure you can get used to it in time, but why bother when decimals are easier and more intuitive? The advantage when converting to and from binary is trivially small.

The second reason is that once you're dealing with values over F they all start to look alike, so any screenful of hex looks like any other at first glance. With decimal values, there are three sets of distinct values which stand out if you don't display leading zeros, and a fourth set if you count those of 200 and above which also jump out at you fairly easily. Of course, by indexing the code it's easy to find your way around most of it anyway, but sometimes there are long stretches without any indexed bytes in them, so the way that patterns show up in the code is really helpful, particularly when you need to find your place again after looking away from the screen for a moment. Using decimals also helps to show up the places where multi-byte instructions start and end, though you have to work with programming directly in machine code for some time before you tune into that. It may be that you could do the same with hex, but I reckon trying to read through code at speed would be much harder. I've always intended to put in a switch at some point to convert the whole display and input system to hex for people who prefer it, but it hasn't been a priority as I'll never want to use it myself. I'll get round to it some day. I also originally planned to add a system for using mnemonics such as CA for mov eax,ecx and c-a for sub ch,ah for input and display of code bytes, but I found the raw numbers so easy to work with that I dropped the idea permanently.

Solar wrote:David claims that decimal notation allows him to "read" the program flow more easily, and that hex hides information from him.

Hex doesn't hide anything - it's just far too alien for my liking. Decimals are easy.

DavidCooper wrote:

Solar wrote:David claims that decimal notation allows him to "read" the program flow more easily, and that hex hides information from him.

Hex doesn't hide anything - it's just far too alien for my liking. Decimals are easy.

If you hide it doesn't mean you're invisible. In other words, what Solar said

Besides, I wouldn't know what EB FE or CD 3F would look like in decimal in a second, let alone recognise the sequences if I'm not aware of it.

This is all highly OT, but for the benefit of newcomers:

• It is much easier to transfer hex to binary (since each digit corresponds 1:1 with a half-byte) than doing the same with decimal.
• David has a point regarding the visuals of one, two, and three digit decimals, but CPU opcodes simply aren't grouped accordingly to make those visual groupings generally meaningful. Opcodes are grouped by bit patters, which are easier read in hex.
• Virtually all relevant documentation is using hex.
• Most if not all tools use hex as both input and output.

I accept that decimal is the format of choice for David, and I admit there's some "leetness" in reading binary directly. But there is a (couple of) reason(s) why people, documentation and tools use hex for this.

Firstly, hex is alien to those of us who grew up using a human language with a base 10 number system...

No more alien than "speaking" a programming language. It all boils down to being used to one or the other. And, as I said, I bow to your choice of using decimals because that's what you grew used to, but I will always and strongly recommend a newcomer getting used to hex.

Just like I recommend my child to learn English as first foreign language, not Latin.

DavidCooper wrote:The second reason is that once you're dealing with values over F they all start to look alike, (...) but I found the raw numbers so easy to work with that I dropped the idea permanently.

Thanks for answering. Though I understand Solar's reasoning above, I can see someone getting accustomed to decimal. And, of course, Intel opcodes are best read in octal anyway :).

So, when writing the code, do you actually think in opcodes? Or do you just think "reg 3 := reg 2", so that's 137 209?


JAL

Just like I recommend my child to learn English as first foreign language, not Latin.

Right. If you want to know what happens with people who learn Latin first, just look at me.

Solar wrote:This is all highly OT,

Optometry Today? Occupational therapy? (Google didn't help.)

It is much easier to transfer hex to binary (since each digit corresponds 1:1 with a half-byte) than doing the same with decimal.

It is significantly easier, I agree, but the need to do this isn't common enough for it to be a real issue. If it was, I'd have written a converter into my OS long ago.

David has a point regarding the visuals of one, two, and three digit decimals, but CPU opcodes simply aren't grouped accordingly to make those visual groupings generally meaningful.

They aren't grouped deliberately to make them visually distinct, but there are accidental patterns which show up all over the place which make it easy to know where you are in a piece of code. The same happens with Z80 code (which I originally used), but the patterns are very different. The same will doubtless happen with most instruction sets, though I think Itanium would need a very different approach - I was looking forward to working with that, but it doesn't look as if it's going to survive.

Opcodes are grouped by bit patters, which are easier read in hex.

The first part of that's true, but you quickly learn to recognise all the multiples of 8 between 0 and 256, so it makes no difference.

Virtually all relevant documentation is using hex.

Which means I have to translate port addresses and the like before I can use them, but again it's nowhere near common enough to compensate for the disadvantages.

Most if not all tools use hex as both input and output.

I don't use other people's tools, but clearly anyone who wants to do so is going to be better off using hex. I realise now that I should put the time into creating a hex mode for my OS so that people who want to become part of the establishment can use my OS to get a proper feel for what goes on underneath assembler without being forced into using decimals. Thank you for helping me see that this is an important issue.

I'm not trying to convert anyone who programs in more conventional ways to using decimals and I don't recommend that beginners use decimals and shun hex in the way that I do - I've simply avoided hex, assembler and programming languages because I find that they get in the way of programming by making it far more complex and unintuitive than it should be. Decimal is our native way of thinking about numbers, and speaking to the processor directly through numbers is for me the easiest way to work. I have always found it difficult to adapt to other people's ways of doing things if they involve unnecessary complexity or have arbitrary aspects to them which don't work the way I would have designed them to - it leads to all manner of bugs which are hard to track down because I simply can't learn and hold all that junk in my head. By working with raw machine code numbers, the complexity is minimised and I always know exactly what I'm getting - if a piece of my code doesn't work, I know for certain that it's my fault, and I never have to trawl through complex documentation to find out if I'm using the tools properly.

No more alien than "speaking" a programming language. It all boils down to being used to one or the other. And, as I said, I bow to your choice of using decimals because that's what you grew used to, but I will always and strongly recommend a newcomer getting used to hex.

Just like I recommend my child to learn English as first foreign language, not Latin.

Decimal is their native language, so it isn't equivalent to learning a second language. What it really comes down to is this - if you have no desire to do anything other than program in machine code, you'll probably be better off using decimals. If you want to use assembler and intend to work with other people's code and for them to work with yours, then you'd be better off using hex. If you want to use a compiler and are likely to need to use a lot of inline assembly, then again you'd be better off with hex. So, most people will need hex. I need to write that hex mode into my OS.

jal wrote:Thanks for answering. Though I understand Solar's reasoning above, I can see someone getting accustomed to decimal. And, of course, Intel opcodes are best read in octal anyway .

In truth, I think it would be perfectly practical to work in base 256 or even 13 if you wanted to - you would soon learn which values map to which instructions. Base 8 might indeed be the most efficient one to use, so maybe I should support it as well, although I can't really see anyone giving it a serious go. Of course, no one would give hex a serious go either if it wasn't already well established - it ought to be nothing more than a historical relic, but it carries so much momentum that it will doubtless continue to dominate until human programmers are made redundant.

So, when writing the code, do you actually think in opcodes? Or do you just think "reg 3 := reg 2", so that's 137 209?

If I want to copy register D (normally called edx) to register C (ecx) I automatically think 139 for the first instruction byte, then 200 for copying to C, then I add 2 to copy from D, so the second instruction byte is 202. Assemblers and compilers appear to use 137 instead of 139 (I don't know if there's a speed difference - if there is I'll need to change a lot of my code, but I plan to write a code optimisation program anyway at some point which should be able to fix things like that automatically), so the second byte will be 208 for copying from D, plus 1 for copying to C. Either way, I bypass the 192 + 8 or 192 + 16 step as I've memorised the values 192, 200, 208, 216, 224, 232, 240 and 248 and know which registers they relate to - you'd be hard pushed not to memorise that kind of thing if you program in machine code for any length of time because they just fix themselves in your mind.

DavidCooper wrote:

Solar wrote:This is all highly OT,

Optometry Today? Occupational therapy? (Google didn't help.)

Dude, you have a communication issue. I recommend http://www.gaarde.org/acronyms/.

(OT: Off-Topic)

DavidCooper wrote:Assemblers and compilers appear to use 137 instead of 139 (I don't know if there's a speed difference

I very much doubt there's any speed difference, even on the 8086. I can see assemblers using 137, as it's just the first one available.


JAL