Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #3210 > unrolled thread

scan for a-z

Back to article view | Back to comp.os.msdos.programmer

Contents

  scan for a-z T. Ment <t.ment@protocol.invalid> - 2019-04-01 22:43 +0000
    Re: scan for a-z "Alexei A. Frounze" <alexfrunews@gmail.com> - 2019-04-01 21:04 -0700
      Re: scan for a-z T. Ment <t.ment@protocol.invalid> - 2019-04-02 16:31 +0000
      Re: scan for a-z Steve Nickolas <usotsuki@buric.co> - 2019-04-02 12:40 -0400
        Re: scan for a-z T. Ment <t.ment@protocol.invalid> - 2019-04-02 16:48 +0000
          Re: scan for a-z Rod Pemberton <invalid@lkntrgzxc.com> - 2019-04-02 18:03 -0400
          Re: scan for a-z Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2019-04-17 23:56 +1000
    Re: scan for a-z "R.Wieser" <address@not.available> - 2019-04-02 09:00 +0200
      Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-02 09:06 +0000
        Re: scan for a-z "R.Wieser" <address@not.available> - 2019-04-02 14:37 +0200
    Re: scan for a-z Herbert Kleebauer <klee@unibwm.de> - 2019-04-02 12:39 +0200
      Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-02 14:27 +0000
        Re: scan for a-z Herbert Kleebauer <klee@unibwm.de> - 2019-04-02 20:17 +0200
          Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-02 19:16 +0000
          Re: scan for a-z wolfgang kern <nowhere@never.at> - 2019-04-03 16:13 +0200
            Re: scan for a-z T. Ment <t.ment@protocol.invalid> - 2019-04-03 19:36 +0000
            Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-04 14:43 +0000
              Re: scan for a-z wolfgang kern <nowhere@never.at> - 2019-04-05 00:41 +0200
    Re: scan for a-z JJ <jj4public@vfemail.net> - 2019-04-02 19:53 +0700
    Re: scan for a-z Mateusz Viste <mateusz@cant.remember> - 2019-04-02 13:00 +0000
      Re: scan for a-z T. Ment <t.ment@protocol.invalid> - 2019-04-02 16:44 +0000
    Re: scan for a-z Rod Pemberton <invalid@lkntrgzxc.com> - 2019-04-02 18:04 -0400
      Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-03 09:31 +0000
        Re: scan for a-z "Alexei A. Frounze" <alexfrunews@gmail.com> - 2019-04-03 02:48 -0700
          Re: scan for a-z "Kerr-Mudd,John" <notsaying@invalid.org> - 2019-04-03 12:25 +0000
            Re: scan for a-z Rod Pemberton <invalid@lkntrgzxc.com> - 2019-04-03 18:05 -0400
        Re: scan for a-z Bogus@Embarq.com (Steve) - 2019-04-03 11:58 +0000
    Re: scan for a-z wolfgang kern <nowhere@never.at> - 2019-04-03 15:58 +0200
      Re: scan for a-z wolfgang kern <nowhere@never.at> - 2019-04-03 16:05 +0200
      Re: scan for a-z "R.Wieser" <address@not.available> - 2019-04-03 17:40 +0200
      Re: scan for a-z "R.Wieser" <address@not.available> - 2019-04-03 17:47 +0200

Page 1 of 2  [1] 2  Next page →

#3210 — scan for a-z

I have a buffer, 8+3 bytes (DOS file name and extension). I want to know
if any character is lowercase, because then I must convert the buffer to
uppercase.

I could write a C loop and check each character with islower(), but 90%
of my data is already uppercase, and there's a lot of data, so that's a
lot of wasted cycles.

There is ASM scasb, but that only looks for a single value, and I need
to look for any character in the range a-z. I guess there's no efficient
way of doing this, without looking at each character, one by one. Am I
missing anything?

[toc] | [next] | [standalone]

#3211

On Monday, April 1, 2019 at 3:43:44 PM UTC-7, T. Ment wrote:
> I have a buffer, 8+3 bytes (DOS file name and extension). I want to know
> if any character is lowercase, because then I must convert the buffer to
> uppercase.
> 
> I could write a C loop and check each character with islower(), but 90%
> of my data is already uppercase, and there's a lot of data, so that's a
> lot of wasted cycles.
> 
> There is ASM scasb, but that only looks for a single value, and I need
> to look for any character in the range a-z. I guess there's no efficient
> way of doing this, without looking at each character, one by one. Am I
> missing anything?

You could just compare all chars to have ASCII codes
less than that of 'a', which may be faster than
the full test, especially if it results in a function
call.

You could probably even handle multiple characters at
once by using SSE instructions, see e.g.
https://stackoverflow.com/a/37151084/968261

But ultimately the question is how slow is slow and
that only you know.

Alex

[toc] | [prev] | [next] | [standalone]

#3219

On Mon, 1 Apr 2019 21:04:17 -0700 (PDT), Alexei A. Frounze wrote:

>You could just compare all chars to have ASCII codes
>less than that of 'a', which may be faster than
>the full test, especially if it results in a function
>call.

Good idea. One test instead of two. But if false, a second test for
greater than 'z' is still needed. But most data would be true on the
first test.


>You could probably even handle multiple characters at
>once by using SSE instructions, see e.g.
>https://stackoverflow.com/a/37151084/968261

I assume 8086, no higher. Otherwise, some of that would be interesting.


>But ultimately the question is how slow is slow and
>that only you know.

The xlat idea would be fine for uppercase conversion, since it happens
rarely. But xlat'ing each character, one at a time, is wasteful for most
of my data, which does not need conversion.

I wish for an instruction that scans for a range (a-z) in one test. Then
the single character conversion overhead becomes acceptable.

But I see there are none on 8086. So the hard way is the only way.

[toc] | [prev] | [next] | [standalone]

#3220

For what it's worth, let's say I had a C string, and I wanted to upcase 
it.

Now, I don't speak 8086 asm, so bear with me, because I'm going to use the 
only dialect I know - 6502.  But the logic would probably be the same as 
8086.

ptr        =        $04
entry:    ldy       #$00
@1:       lda       (ptr), y
           beq       @3
           cmp       #'a'
           bcc       @2        ; less than
           cmp       #'z'+1
           bcs       @2        ; greater or equal
           and       #$5F
           sta       (ptr), y
@2:       iny
           bne       @1
@3:       rts

-uso.

[toc] | [prev] | [next] | [standalone]

#3222

On Tue, 2 Apr 2019 12:40:41 -0400, Steve Nickolas wrote:

>Now, I don't speak 8086 asm, so bear with me, because I'm going to use the 
>only dialect I know - 6502.  But the logic would probably be the same as 
>8086.
>
>ptr        =        $04
>entry:    ldy       #$00
>@1:       lda       (ptr), y
>           beq       @3
>           cmp       #'a'
>           bcc       @2        ; less than
>           cmp       #'z'+1
>           bcs       @2        ; greater or equal
>           and       #$5F
>           sta       (ptr), y
>@2:       iny
>           bne       @1
>@3:       rts

I have no knowledge of 6502. If anyone can translate to 8086, please do.

[toc] | [prev] | [next] | [standalone]

#3225

On Tue, 02 Apr 2019 16:48:41 +0000
T. Ment <t.ment@protocol.invalid> wrote:

> On Tue, 2 Apr 2019 12:40:41 -0400, Steve Nickolas wrote:

> >Now, I don't speak 8086 asm, so bear with me, because I'm going to
> >use the only dialect I know - 6502.  But the logic would probably be
> >the same as 8086.
> >
> >ptr        =        $04
> >entry:    ldy       #$00
> >@1:       lda       (ptr), y
> >           beq       @3
> >           cmp       #'a'
> >           bcc       @2        ; less than
> >           cmp       #'z'+1
> >           bcs       @2        ; greater or equal
> >           and       #$5F
> >           sta       (ptr), y
> >@2:       iny
> >           bne       @1
> >@3:       rts  
> 
> I have no knowledge of 6502. If anyone can translate to 8086, please
> do.

It's been a long time since I did 6502.  But, roughly translated ...


  entry:     cld
             mov esi,[ptr]   ; ptr contains address of buffer
             mov edi,esi
             add edi,length_of_buffer+1
  @1:        lodsb
             or al,al        ; set flags
              jz  @3         ; nul terminated buffer/string
              cmp  al,'a'
              jb  @2
              cmp  al,'z'+1
              jae @2
              and  al,5Fh
              dec esi
              stosb
  @2:         cmp esi,edi
              jne @1
  @3:        ret


For x86, XLATB is a better solution, since the "complicated" 6502
indirect addressing modes don't exist on x86.
http://qcd.phys.cmu.edu/QCDcluster/intel/vtune/reference/vc327.htm


Rod Pemberton
-- 
The lesson for Boeing.  You push the nose of a plane down, and planes
go down.

[toc] | [prev] | [next] | [standalone]

#3256

Groovy hepcat T. Ment was jivin' in comp.os.msdos.programmer on Wed, 3
Apr 2019 03:48 am. It's a cool scene! Dig it.

> On Tue, 2 Apr 2019 12:40:41 -0400, Steve Nickolas wrote:
> 
>>Now, I don't speak 8086 asm, so bear with me, because I'm going to use
>>the
>>only dialect I know - 6502.  But the logic would probably be the same
>>as 8086.
>>
>>ptr        =        $04
>>entry:    ldy       #$00
>>@1:       lda       (ptr), y
>>           beq       @3
>>           cmp       #'a'
>>           bcc       @2        ; less than
>>           cmp       #'z'+1
>>           bcs       @2        ; greater or equal
>>           and       #$5F
>>           sta       (ptr), y
>>@2:       iny
>>           bne       @1
>>@3:       rts
> 
> I have no knowledge of 6502. If anyone can translate to 8086, please
> do.

  I'll give it a go, but it's been quite some time since I've done any
8086 assembly.

            ptr equ $04
            mov si, 0
@1:         mov al, [si] + ptr
            je @3
            cmp al, 'a'
            jl @2
            cmp al, 'z" + 1
            jge @2
            and al, $5f
            mov [si] + ptr, al
@2:         inc si
            jmp @1
@3:         ret

  I hope I've got that right. How it works:

1) The string to be checked is apparently at address $04 (if I've
understood correctly). ptr represents this address.

2) We use an index register (y in 6502, si in 8086) to access characters
within the string. Start by setting this to 0 to select the first
character.

3) Get the selected character from the string.

4) If it's a nul, skip to step 9.

5) If the character is less than a lower case 'a', skip to step 8.

6) If the character is greater than or equal to lower case 'z' + 1 (in
other words, is greater than 'z'), skip to step 8.

7) By this point, the character must be a lower case letter. Clear bit 6
(and bit 7, but that is always 0 in ASCII) to make it capital.

8) Increment the index register to select the next character before
jumping back to step 3. The 6502 version uses a conditional branch
here, no doubt since the original 6502 lacks an unconditional branch.
(The 65C02 has such an instruction, however.) I've used an
unconditional branch in the 8086 version.

9) End.

-- 


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!

[toc] | [prev] | [next] | [standalone]

#3212

T,

> I guess there's no efficient way of doing this, without looking
> at each character, one by one.

Pray tell, how can you make sure that none of the cookies in a jar is a 
chocolate-chip one (which you crave and want to eat) without examining them 
one-by-one ? :-)

> but 90% of my data is already uppercase, and there's a lot of data,
> so that's a lot of wasted cycles.

Easy: Just remove that 90% from the string and you will get a 100% 
conversion rate.

How you c|should remove that 90% ?   I haven't got the foggiest. Probably by 
checking all characters one-by-one and weed the already-uppercase ones out 
... :-)

In other words, you're making a problem of something that cannot be solved 
in any other way (than maybe, just /maybe/, by handling multiple chars at a 
time, filling out a 16/32 bit register ...)

The easiest/fastest way to check each of those characters (lodsb) is 
subtract ('a') and compare (26).  If equal-or-higher (not a lower-case char) 
jump to advance to the next char.  Otherwise add ('A') and store (at esi-1) 
(and than advance).

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#3213

On Tue, 02 Apr 2019 07:00:38 GMT, "R.Wieser" <address@not.available>
wrote: 

> T,
> 
>> I guess there's no efficient way of doing this, without looking
>> at each character, one by one.
> 
> Pray tell, how can you make sure that none of the cookies in a jar is
> a chocolate-chip one (which you crave and want to eat) without
> examining them one-by-one ? :-)
> 
>> but 90% of my data is already uppercase, and there's a lot of data,
>> so that's a lot of wasted cycles.
> 
> Easy: Just remove that 90% from the string and you will get a 100% 
> conversion rate.
> 
> How you c|should remove that 90% ?   I haven't got the foggiest.
> Probably by checking all characters one-by-one and weed the
> already-uppercase ones out ... :-)
> 
> In other words, you're making a problem of something that cannot be
> solved in any other way (than maybe, just /maybe/, by handling
> multiple chars at a time, filling out a 16/32 bit register ...)
> 
> The easiest/fastest way to check each of those characters (lodsb) is 
> subtract ('a') and compare (26).  If equal-or-higher (not a lower-case
> char) jump to advance to the next char.  Otherwise add ('A') and store
> (at esi-1) (and than advance).
> 
> Regards,
> Rudy Wieser
> 
> 
IAWTP, but, to narrowly follow your spec, you could 'OR' all the chars 
together, if result >0x20 then you have at least 1 lowercase char, so 
must invoke a conversion rtn.


-- 
Bah, and indeed, Humbug.

[toc] | [prev] | [next] | [standalone]

#3215

John,

> you could 'OR' all the chars together, if result >0x20 then you
> have at least 1 lowercase char, so must invoke a conversion rtn.

Not quite: It would catch /much/ more than just the lower-case chars 
(0x20...0x3F, 0x60, 0x7B...0x7F if only ASCII is considered, otherwise 
0xA0...0xBF, 0xE0...0xFF too).  That includes the digits and a number of 
other ASCII symbols that are valid in 8.3 DOS filenames.   :-\

Regards,
Rudy Wieser




Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#3214

On 02.04.2019 00:43, T. Ment wrote:

> I have a buffer, 8+3 bytes (DOS file name and extension). I want to know
> if any character is lowercase, because then I must convert the buffer to
> uppercase.

In order to convert lowercase to uppercase you don't need
to know if it is lowercase. Just use a 256 byte translation
table to replace any input byte by the proper output byte.

[toc] | [prev] | [next] | [standalone]

#3218

On Tue, 02 Apr 2019 10:39:17 GMT, Herbert Kleebauer <klee@unibwm.de> 
wrote:

> On 02.04.2019 00:43, T. Ment wrote:
> 
>> I have a buffer, 8+3 bytes (DOS file name and extension). I want to 
know
>> if any character is lowercase, because then I must convert the buffer 
to
>> uppercase.
> 
> In order to convert lowercase to uppercase you don't need
> to know if it is lowercase. Just use a 256 byte translation
> table to replace any input byte by the proper output byte.
> 
> 
AND byte [ptrreg],0xDF



-- 
Bah, and indeed, Humbug.

[toc] | [prev] | [next] | [standalone]

#3223

On 02.04.2019 16:27, Kerr-Mudd,John wrote:

>> In order to convert lowercase to uppercase you don't need
>> to know if it is lowercase. Just use a 256 byte translation
>> table to replace any input byte by the proper output byte.
>> 
>> 
> AND byte [ptrreg],0xDF


And what happens to characters which have bit 5 set, but
are nor lowercase letters?

But a XLAT instruction should do the job:


XLAT/XLATB ── Table Look-up Translation

D7    XLAT m8    5     Set AL to memory byte DS:[(E)BX + unsigned AL]
D7    XLATB      5     Set AL to memory byte DS:[(E)BX + unsigned AL]


Operation

IF AddressSize = 16
THEN
    AL . (BX + ZeroExtend(AL))
ELSE (* AddressSize = 32 *)
    AL . (EBX + ZeroExtend(AL));
FI;

Description

XLAT changes the AL register from the table index to the table entry. AL
should be the unsigned index into a table addressed by DS:BX (for an
address-size attribute of 16 bits) or DS:EBX (for an address-size attribute
of 32 bits).

The operand to XLAT allows for the possibility of a segment override. XLAT
uses the contents of BX even if they differ from the offset of the operand.
The offset of the operand should have been moved intoBX/EBX with a previous
instruction.

The no-operand form, XLATB, can be used if the BX/EBX table will always
reside in the DS segment.

Flags Affected

None

[toc] | [prev] | [next] | [standalone]

#3224

On Tue, 02 Apr 2019 18:17:29 GMT, Herbert Kleebauer <klee@unibwm.de>
wrote: 

> On 02.04.2019 16:27, Kerr-Mudd,John wrote:
> 
>>> In order to convert lowercase to uppercase you don't need
>>> to know if it is lowercase. Just use a 256 byte translation
>>> table to replace any input byte by the proper output byte.
>>> 
>>> 
>> AND byte [ptrreg],0xDF
> 
> 
> And what happens to characters which have bit 5 set, but
> are nor lowercase letters?
> 
> But a XLAT instruction should do the job:

[]

Fair enough.


-- 
Bah, and indeed, Humbug.

[toc] | [prev] | [next] | [standalone]

#3234

On 02.04.2019 20:17, Herbert Kleebauer wrote:
....

>> AND byte [ptrreg],0xDF

> And what happens to characters which have bit 5 set, but
> are nor lowercase letters?

it's about filenames ... can they contain 20..2F ?
IF SPACE and friends are allowed then it's a problem of course.
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#3237

On Wed, 3 Apr 2019 16:13:22 +0200, wolfgang kern wrote:

> it's about filenames ... can they contain 20..2F ?
> IF SPACE and friends are allowed then it's a problem of course.

In DOS 6.22

    echo abc > #%

creates a file named #%. Unusual maybe, but legal. Names like that may
have a purpose, such as a directory name that always appears first, or a
name that software packages are unlikely to use.

Bit tricks are good for some things. But not this.

[toc] | [prev] | [next] | [standalone]

#3239

On Wed, 03 Apr 2019 14:13:22 GMT, wolfgang kern <nowhere@never.at> wrote:

> On 02.04.2019 20:17, Herbert Kleebauer wrote:
> ....
> 
>>> AND byte [ptrreg],0xDF
> 
That was me
>> And what happens to characters which have bit 5 set, but
>> are nor lowercase letters?
> 
> it's about filenames ... can they contain 20..2F ?
> IF SPACE and friends are allowed then it's a problem of course.

but he's right, all numbers get nobbled as well.
> __
> wolfgang



-- 
Bah, and indeed, Humbug.

[toc] | [prev] | [next] | [standalone]

#3240

On 04.04.2019 16:43, Kerr-Mudd,John wrote:
> On Wed, 03 Apr 2019 14:13:22 GMT, wolfgang kern <nowhere@never.at> wrote:

>> On 02.04.2019 20:17, Herbert Kleebauer wrote:
>> ....

>>>> AND byte [ptrreg],0xDF

> That was me
>>> And what happens to characters which have bit 5 set, but
>>> are nor lowercase letters?
>>
>> it's about filenames ... can they contain 20..2F ?
>> IF SPACE and friends are allowed then it's a problem of course.

> but he's right, all numbers get nobbled as well.

Yeah, there were no numbers nor any outside 40..7F in my scenario :)
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#3216

On Mon, 01 Apr 2019 22:43:43 +0000, T. Ment wrote:
> I have a buffer, 8+3 bytes (DOS file name and extension). I want to know
> if any character is lowercase, because then I must convert the buffer to
> uppercase.
> 
> I could write a C loop and check each character with islower(), but 90%
> of my data is already uppercase, and there's a lot of data, so that's a
> lot of wasted cycles.
> 
> There is ASM scasb, but that only looks for a single value, and I need
> to look for any character in the range a-z. I guess there's no efficient
> way of doing this, without looking at each character, one by one. Am I
> missing anything?

IMO, nothing is more efficient because checking whether a character is
lowercase or not, requires one additional check: whether a character is an
alphabet or not.

Moreover, when a character is found as lowercased, you'll need to convert it
to uppercase anyway. So if performance is needed, the character should
already have been stored in a register.

If you want to make sure all file names are uppercased, you should convert
them to uppercase at the time they are made. e.g. if the file name is
inputted manually by user, then make the program convert it to uppercase
right after the input is accepted. If you have no control over that program,
create a program which converts the file names to uppercase for newly
created files, and make it run after the program which created the files has
ended.

[toc] | [prev] | [next] | [standalone]

#3217

On Mon, 01 Apr 2019 22:43:43 +0000, T. Ment wrote:
> I have a buffer, 8+3 bytes (DOS file name and extension). I want to know
> if any character is lowercase, because then I must convert the buffer to
> uppercase.

I do not know the target use you are thinking about, but perhaps
INT 21,AH=60h could fit the bill?

(INT 2F,AX=1211h is also nice, but somewhat exotic)

Mateusz

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.msdos.programmer

csiph-web