Uppercase and lowercase output in Hex to string function

[phillid]

Hang on.

This morning, I re-assembled and the problem went away. I then loaded a disk image I that I took from the assemble after which I noticed the problem. I booted and the problem wasn't there.

[iansjack]

Now you are in a worse position than you were before. Something unexpected happened which you can't now reproduce. You can put that down to serendipity, but it will happen again some time probably in a more important bit of code. You really need to find out what you were doing wrong.

If you think that the DF flag makes no difference try single stepping through some code that uses stosb to store a few bytes. Try it with DF clear and then with it set and take note of the difference, in particular what happens to %di. Better still, read the documentation to find what the direction flag does.

I'm still interested to know how you were putting the initial value into %al. How did you enter 0x2B as opposed to 0x2b?

[Love4Boobies]

The problem didn't go away. The OP was either trolling or thought (s)he observed something (s)he actually didn't. At any rate, if I were you, I'd probably do something like the following instead:

Code: Select all

        mov     bx, hex
        mov     di, result
        mov     ah, al
        and     al, 1111b
        xlatb
        stosb
        shr     ax, 12
        xlatb
        stosb

Code: Select all

hex:    db      '0123456789ABCDEF'
result: resw    1

[Love4Boobies]

Indeed, it should. I didn't test it, I just wrote it in a hurry. Thanks for pointing that out.

EDIT: I also separated the data from the code so no one would complain, although I think it was obvious that the OP would have to place them separately.

[iansjack]

The OP was either trolling or thought (s)he observed something (s)he actually didn't.

Since the OP doesn't realise the significance of the direction flag when using the string instructions I'm going to be generous and suppose that a random value here was the problem (and that they put the value 0x2B or 0x2b in the buffer in the first place).

[phillid]

I DO understand the importance of the direction flag when performing string instructions! What I said was that it wouldn't make a capital letter be lowercase or the other way around!

With regards to how I was storing the hex value, I stored it using:

Code: Select all

mov al, 0x2b

[iansjack]

I DO understand the importance of the direction flag when performing string instructions! What I said was that it wouldn't make a capital letter be lowercase or the other way around!

What you said was:

The direction flag shouldn't have any effect, should it?

Hmm. I think you still don't appreciate the significance of the flag. If it was set to decrement then the second character wouldn't be put in the buffer so you could well get the result you describe. It depends upon what was in the buffer to start with.

As to storing the value in %al in the first place, single-stepping through that single line of code would be enough to show you that there is no difference between 0x2B and 0x2b. I still think you need to improve your debugging skills (especially if you spend 99% of your time doing it). What you have told us so far demonstrates that you really don't know how to use a debugger.

Anyway, that's enough from me. It's fairly clear that you are not willing to listen to advice.

[phillid]

I think you still don't appreciate the significance of the flag. If it was set to decrement then the second character wouldn't be put in the buffer so you could well get the result you describe. It depends upon what was in the buffer to start with.

I tested it with multiple values including 0x2B, so I should have gotten '2_' in the buffer if the direction flag was set?

As to storing the value in %al in the first place, single-stepping through that single line of code would be enough to show you that there is no difference between 0x2B and 0x2b

EXACTLY. THAT IS WHY I POSTED THIS THREAD. I was confused because I understand that there is no difference between 0x2B and 0x2b!

Anyway, that's enough from me. It's fairly clear that you are not willing to listen to advice.

To me it is clear that you still do not understand my problem properly, perhaps it is my error.

I shall make it crystal clear what the problem was
The following code gave the following results:

Code: Select all

mov al, 0x2b
call HexToString
; Buffer was '2b'

Code: Select all

mov al, 0x2B
call HexToString
; Buffer was '2B'

Code: Select all

mov al, 0xfF
call HexToString
; Buffer was 'fF'

Code: Select all

mov al, 0xFF
call HexToString
; Buffer was 'FF'

Code: Select all

mov al, 0x19
call HexToString
; Buffer was '19'

To find out what the buffer was, I printed it to the screen. Is someone going to suggest that I post my function for printing to the screen on the forum?

[Solar]

Well, apparently the code you posted did not / was not sufficient to exhibit the behaviour you described, so it does not contain the error...

[phillid]

Yes..

Well, look, I'm sorry for ending up wasting people's time in the end as the bug disappeared. I'll leave the code as it is now and continue development.

I do realise that it's not good practice to do this but I'm really not getting anything but insults when it all boils down.

Thanks for your help anyway, I've learnt some techniques from the two sample code snippets posted by other members on this thread.

[Solar]

I've learnt some techniques from the two sample code snippets posted by other members on this thread.

I really don't want to flame, but I hope you learned more than that. Isolating faulty code in a functional example is one of the most important debugging techniques, and a prerequisite for asking a smart question on the 'web.

[phillid]

I've learnt some techniques from the two sample code snippets posted by other members on this thread.

I really don't want to flame, but I hope you learned more than that. Isolating faulty code in a functional example is one of the most important debugging techniques, and a prerequisite for asking a smart question on the 'web.

Of course I learned about isolating code, I'm not going to list every single thing that I learned

[iansjack]

To find out what the buffer was, I printed it to the screen. Is someone going to suggest that I post my function for printing to the screen on the forum?

It could be that you have now isolated your fault. As the result you describe is impossible it's a possibility that you are not in fact printing the buffer at all (and, no, I don't want to see the code that you used for that).

At the risk of repeating myself yet again, the best way to see what is really happening is to single-step through the code watching registers and memory locations at every step. This is such a simple process that you could have saved yourself a lot of trouble by doing that rather than starting this rather pointless thread.