some questions 
Author Message
 some questions

I have tried this:

getc_in:
 mov  ah, 0
 int  16h
 ret
but, is there any sys-way (not dos int 21) for gets a char without
waste cpu cycles?

Why in NASM don't exist "push  ah"?
Is that a cpu instruction or a macro in MASM?

Why "mov ax, ip" is not recognized?
Thanks



Tue, 28 Jun 2005 07:20:21 GMT  
 some questions

Quote:

> I have tried this:

> getc_in:
>  mov  ah, 0
>  int  16h
>  ret
> but, is there any sys-way (not dos int 21) for gets a char without
> waste cpu cycles?

I'm not sure just what you're looking for here. Under "normal"
conditions, when a key is hit (or released!), it triggers an irq 1/int
9. You can, if you wish, completely replace the int 9 handler, and do
anything you like with it. (there's an int 9 replacement in the AoA
example code - chapter 21???) The existing int 9 handler, besides a lot
of checking and housekeeping, puts a "normal" key in the keyboard buffer
in the Bios Data Area, and updates the "head" pointer (it may use an int
16h subfunction to do this). You could emulate the effect of int 16h/0
by comparing the "head" pointer with the "tail" pointer (to the keyboard
buffer). If they're the same, no key is ready, so we wait. In a
multitasking OS, it would be polite to give up the rest of your
timeslice at this point. In a single-tasking system, I guess you'd just
wait in a loop until an interrupt occurs, and "head" and "tail" differ.
(Windows may mess with this in a dos-box, via "idle sensitivity"). Then
fetch the key (ascii code and scancode), and update the "tail" pointer.
(to do int 16h/1, you'd just return if no key ready - if so, fetch the
key and *don't* update the tail pointer.)

I don't know if that's any help - I'm not sure why you're worrying about
CPU cycles in a "wait for a key" routine...

Quote:
> Why in NASM don't exist "push  ah"?
> Is that a cpu instruction or a macro in MASM?

> Why "mov ax, ip" is not recognized?

No such instructions. If Masm will let you do "push ah", it's gotta be a
macro (and doesn't make much sense to me, at that - what's "pop ah"
supposed to do???). You can get at (e)ip by issuing a call - that'll
"push" ip on the stack - then you can pop it off, or actually have a
subroutine that fetches ip off the stack and issues a "ret". The latter
is apparently better for P-4, which keeps track of call-return pairs for
"prediction" purposes(?). (But Wolfgang has posted some
sensible-sounding reasons why it's not worth worrying about. I really
don't know. Verify, verify, verify!)

Best,
Frank



Tue, 28 Jun 2005 09:18:22 GMT  
 some questions

Quote:

>I have tried this:

>getc_in:
> mov  ah, 0
> int  16h
> ret
>but, is there any sys-way (not dos int 21) for gets a char without
>waste cpu cycles?

You could access the keyboard input buffer that is maintained
by the BIOS directly. The keyboard buffer is a 32 byte circular
queue in the BIOS data segment (40:0), 1 word is kept in there
for each key pressed

40:1A (word)    = offset of head pointer ( from 40:0 )
40:1C (word)    = offset of tail pointer ( from 40:0 )
40:1E (32bytes) = keyboard buffer

( for reference on BIOS /DOS memory structures a good source
is something called DOSREF, try searching on the ftp search engine
 http://www.filesearching.com for a copy of that )

If the 2 pointers are the same then there is no key in the buffer
so you can check for a key waiting by simply comparing them,
if they are equal and you wish to emulate INT 16 /AH=00 then
you might loop until they are not equal, get the key value from
the buffer directly then update the pointer to delete it.

At least for checking if a key has been pressed or not this should
be much faster than the BIOS routine (AH=01/INT 16) however for
waiting for a key press I can't see how you are going to get any
advantage in speed, the overhead you cut from bypassing the BIOS
is going to be very small in comparison with the speed a human
can input those key presses (although possibly you may gain if
the keys are being fed to the program via some monitoring code
like in the Windows VDM when pasting from the GUI)

Quote:

>Why in NASM don't exist "push  ah"?

The op-code doesn't exist in the CPU machine code basically because
the stack is 16-bit (it can be 32-bit in 32-bit mode but never 8-bit)

At the level of assembler it is feasible that they could have added
a psuedo-instruction (*) which had the effect of pushing a word with
the most significant byte equal to 0 and the least significant equal
to AH, however the equivalent code to do that would be a bit long
winded really....

(*) 'NOP' is really an assembler psuedo-instruction
itself because in machine code the x86 doesn't have this instruction,
usually the assembler encodes 'NOP' as an 'XCHG AX,AX'

Quote:
>Is that a cpu instruction or a macro in MASM?

>Why "mov ax, ip" is not recognized?

IP isn't accessible as a general register is, this again is due to
the design of the CPU and not the assembler itself. Since they decided
to put a register field directly into the op-codes the space is very
limited; the more registers you can address the more op-codes there
need to be., most programs won't need to read or write the IP other
than indirectly when the special instructions like CALL / JMP / RET,.,,
come into play. If you want to get the value of IP in your program
you can get it quite easily however;

CALL labl
labl:
POP AX

This code puts the value of IP at the point of label  'labl'
into AX. It works because CALL itself pushes the value of IP (at the
point just after the CALL instruction) onto the stack, so instead
of eating up the value with the normal RET you just take it for yourself
with the POP.

      This is more long winded than having one instruction
to do the task however it doesn't come up very often in programming
(most often when it does it is only used once because once the
program knows the value of IP at one point it can calculate what
it would be at other points by just adding or subtracting)
if they had put IP and allowed you to access it just like normal
registers then they would have ;

(i) added lots of quirky/redundant instructions which will mostly be useless
    although x86 has lots of these already

(ii) taken up valuable space in the op-code map which will increase
     the size of most codes needlessly

Like this you have the best of both worlds, because you can still
perform the operation and it's still easy to code... :-)

Quote:
>Thanks

bestwishes
laura


Tue, 28 Jun 2005 10:21:36 GMT  
 some questions

Quote:

> (*) 'NOP' is really an assembler psuedo-instruction
> itself because in machine code the x86 doesn't have this instruction,
> usually the assembler encodes 'NOP' as an 'XCHG AX,AX'

   Nope, NOP is "true" instruction that does nothing, not a "pseudo".
There's only one NOP (opcode 90h), it just happens to be encoded as
"XCHG AX, AX". Update of AX register doesn't happen, but it happens in
other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
AX, AX (opcode 87h 0C0h).

/BP



Tue, 28 Jun 2005 19:52:43 GMT  
 some questions
Actually, there are many NOP's on the x86, such as MOV AX,AX or LEA AX,[AX]
or the normal XCHG AX,AX , not to mention the above with BX, CX, DX, SI or
DI, and not to mention stuff like SHR reg,0 or stuff like that. XCHG AX,AX
was just named NOP because it was the only single-byte operation that did
nothing.


Quote:

> > (*) 'NOP' is really an assembler psuedo-instruction
> > itself because in machine code the x86 doesn't have this instruction,
> > usually the assembler encodes 'NOP' as an 'XCHG AX,AX'

>    Nope, NOP is "true" instruction that does nothing, not a "pseudo".
> There's only one NOP (opcode 90h), it just happens to be encoded as
> "XCHG AX, AX". Update of AX register doesn't happen, but it happens in
> other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
> AX, AX (opcode 87h 0C0h).

> /BP



Tue, 28 Jun 2005 20:11:01 GMT  
 some questions


Quote:

> > (*) 'NOP' is really an assembler psuedo-instruction
> > itself because in machine code the x86 doesn't have this instruction,
> > usually the assembler encodes 'NOP' as an 'XCHG AX,AX'

>    Nope, NOP is "true" instruction that does nothing, not a "pseudo".
> There's only one NOP (opcode 90h), it just happens to be encoded as
> "XCHG AX, AX". Update of AX register doesn't happen, but it happens in
> other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
> AX, AX (opcode 87h 0C0h).

> /BP

Yup, it's right to say that NOP is *not* XCHG AX,AX, because in modern
(and probably even past) CPU's XCHG AX,AX is a special, h/w optimized
instruction that executes faster than e.g. XCHG AX,DX (opcode $91),
creates no dependances, etc..


Tue, 28 Jun 2005 22:05:04 GMT  
 some questions

Quote:

> Actually, there are many NOP's on the x86, such as MOV AX,AX or LEA AX,[AX]
> or the normal XCHG AX,AX , not to mention the above with BX, CX, DX, SI or
> DI, and not to mention stuff like SHR reg,0 or stuff like that.

Doesn't "SHR reg,0" modify the flags?

Quote:
> > There's only one NOP (opcode 90h), it just happens to be encoded as
> > "XCHG AX, AX".

Intel says: The NOP instruction is an alias mnemonic for the
            XCHG (E)AX,(E)AX instruction.

Quote:
> > Update of AX register doesn't happen, but it happens in
> > other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
> > AX, AX (opcode 87h 0C0h).

What is the difference between "not update AX register" and "update
AX with it's old value".


Tue, 28 Jun 2005 22:15:58 GMT  
 some questions

Quote:

>I have tried this:

>getc_in:
> mov  ah, 0
> int  16h
> ret
>but, is there any sys-way (not dos int 21) for gets a char without
>waste cpu cycles?

; nasm -f bin -o hash.com hash.asm
        org     100h
        call    setkbirq
        mov     ah,0fh
        int     10h
        mov     byte[old_mode],al
        mov     ax,0eh
        int     10h


        xor     edx,-1
        add     edx,101
        imul    ecx,ebp,10

        add     edx,100
        int     10h
        sub     edx,100
        inc     ecx
        cmp     ecx,630

        inc     ebp
        cmp     ebp,64


        call    resetkbirq
        mov     ax,[old_mode]
        int     10h
        mov     ax,4c00h
        int     21h

        align   16
setkbirq:push   es
        mov     ax,35h << 8 | 9
        int     21h
        mov     [okbirq],bx
        mov     [okbirq+2],es
        mov     ax,25h << 8 | 9
        mov     dx,kbirq
        int     21h
        pop     es
        ret

        align   16
resetkbirq:push ds
        mov     ax,25h << 8 | 9
        lds     dx,[okbirq]
        int     21h
        pop     ds
        ret

        align   16
kbirq:  push    ds
        push    ax
        push    cs
        pop     ds
        in      al,60h
        or      al,al


        out     20h,al
        pop     ax
        pop     ds
        iret


okbirq  dd      0
old_mode dw     0
kb_flg  db      0




Wed, 29 Jun 2005 09:19:54 GMT  
 some questions

Quote:


>> Actually, there are many NOP's on the x86, such as MOV AX,AX or LEA AX,[AX]
>> or the normal XCHG AX,AX , not to mention the above with BX, CX, DX, SI or
>> DI, and not to mention stuff like SHR reg,0 or stuff like that.

> Doesn't "SHR reg,0" modify the flags?

>> > There's only one NOP (opcode 90h), it just happens to be encoded as
>> > "XCHG AX, AX".

> Intel says: The NOP instruction is an alias mnemonic for the
>             XCHG (E)AX,(E)AX instruction.

>> > Update of AX register doesn't happen, but it happens in
>> > other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
>> > AX, AX (opcode 87h 0C0h).

> What is the difference between "not update AX register" and "update
> AX with it's old value".

If you're scheduling instructions, then you probably don't want two
instructions to update the sameregister at the same time. Therefore the
"not update" instruction could operate in parallel with an instruction
that actually modifies that register, but the "update with the same value"
instruction couldn't.

I'm assuming this is an issue on a least some of the x86 families, it's
certainly a consideration on other architectures.

Phil



Wed, 29 Jun 2005 10:29:57 GMT  
 some questions
The instructions I quoted are actually *recommended* by AMD as neutral
code-fillers when more than 1 byte needs to be skipped.


Quote:


> >> Actually, there are many NOP's on the x86, such as MOV AX,AX or LEA
AX,[AX]
> >> or the normal XCHG AX,AX , not to mention the above with BX, CX, DX, SI
or
> >> DI, and not to mention stuff like SHR reg,0 or stuff like that.

> > Doesn't "SHR reg,0" modify the flags?

> >> > There's only one NOP (opcode 90h), it just happens to be encoded as
> >> > "XCHG AX, AX".

> > Intel says: The NOP instruction is an alias mnemonic for the
> >             XCHG (E)AX,(E)AX instruction.

> >> > Update of AX register doesn't happen, but it happens in
> >> > other instructions that "do nothing", like MOV AX, AX or 2-byte XCHG
> >> > AX, AX (opcode 87h 0C0h).

> > What is the difference between "not update AX register" and "update
> > AX with it's old value".

> If you're scheduling instructions, then you probably don't want two
> instructions to update the sameregister at the same time. Therefore the
> "not update" instruction could operate in parallel with an instruction
> that actually modifies that register, but the "update with the same value"
> instruction couldn't.

> I'm assuming this is an issue on a least some of the x86 families, it's
> certainly a consideration on other architectures.

> Phil



Wed, 29 Jun 2005 17:50:45 GMT  
 some questions
Why asm programmers are so few?


Wed, 29 Jun 2005 21:42:09 GMT  
 some questions

Quote:

>Why asm programmers are so few?

Job security :-)
                                     If you turn the clock back
10 years or even just 5 you will see the number of jobs requiring
it go up exponentially even ( for example you can search googles
archive in the jobs newsgroups for 'x86' and 'assembly language' )

Nowadays 95% of positions that want some assembly language only
state 'assembly language experience *desireable' or 'familiarity
with assembly language'. That is not really necessarily a good
litmus test of the way things are going since you do have many
more jobs now than there were, however if you look at the jobs
which were traditionally the province of assembly coders only
you see a sharp decline over the years (games, embedded programming,
operating systems drivers, although these 3 areas still require
assembly programmers but not in such numbers and the size of the
work is being progressively scaled down as they work out how to
replace more and more functionality with C, C++, Java.... actually
working on optimised Java Virtual Machines is one area where they
want *more* assembly coding ability at the moment...

There are a number of reasons why this is happening (an interesting
thing to study is the history use of assembly language in enterprise/HPC
computing) and also why it is a logical progression, taking into account the
'bigger picture' of business economics.... however in the end of the day
no-one has any control over that, that is up to the powers that be.

A consolation is that it is clearly obvious that assembly language
will always be in demand ( if nothing else, someone has to at least
know how to maintain that part of the system ) although I have an idea
that you will either have to have a PhD and immaculate work record
to get in (closed specialism due to being deep inside co-operation, working
for security firms, ....) or it will be work that comes and goes
in different places (as they require the extra input in various areas,
like the sudden requirement for assembly programmers to deal with
the Y2k bug ).

It's just that if the most jobs require no assembly language then
most people will not learn it, and some jobs require a little
therefore a small number will learn the basic idea of it, and
very very few jobs require for you to program fluently entire
applications so a handful of nutcases like me and others on this
group (who do it more for love and science than anything else)
will be like that... It's just common sense really,
it takes an investment in time to program assembly language, the more
time you give it the better you get however you can't give all your
time into programming it because you have to make a living as well
and if everybody wants you to just patch some C/C++ code....

Anyhow, there were never that many assembly programmers really,
(well decent ones anyhow) even in the good old days ;-) Personally
I think that us, like the Forth people are more interested in
computers *themselves* than most people are or ever were. We want
to know who the things work, exactly what they are doing, how
to control it and make it do what we want, how to be able to know
and explain anything that is going on and research new ideas.... :-)

bestwishes
laura



Thu, 30 Jun 2005 02:07:02 GMT  
 some questions

Quote:

>Why asm programmers are so few?

Job security :-)
                                     If you turn the clock back
10 years or even just 5 you will see the number of jobs requiring
it go up exponentially even ( for example you can search googles
archive in the jobs newsgroups for 'x86' and 'assembly language' )

Nowadays 95% of positions that want some assembly language only
state 'assembly language experience *desireable' or 'familiarity
with assembly language'. That is not really necessarily a good
litmus test of the way things are going since you do have many
more jobs now than there were, however if you look at the jobs
which were traditionally the province of assembly coders only
you see a sharp decline over the years (games, embedded programming,
operating systems drivers, although these 3 areas still require
assembly programmers but not in such numbers and the size of the
work is being progressively scaled down as they work out how to
replace more and more functionality with C, C++, Java.... actually
working on optimised Java Virtual Machines is one area where they
want *more* assembly coding ability at the moment...

There are a number of reasons why this is happening (an interesting
thing to study is the history use of assembly language in enterprise/HPC
computing) and also why it is a logical progression, taking into account the
'bigger picture' of business economics.... however in the end of the day
no-one has any control over that, that is up to the powers that be.

A consolation is that it is clearly obvious that assembly language
will always be in demand ( if nothing else, someone has to at least
know how to maintain that part of the system ) although I have an idea
that you will either have to have a PhD and immaculate work record
to get in (closed specialism due to being deep inside co-operation, working
for security firms, ....) or it will be work that comes and goes
in different places (as they require the extra input in various areas,
like the sudden requirement for assembly programmers to deal with
the Y2k bug ).

It's just that if the most jobs require no assembly language then
most people will not learn it, and some jobs require a little
therefore a small number will learn the basic idea of it, and
very very few jobs require for you to program fluently entire
applications so a handful of nutcases like me and others on this
group (who do it more for love and science than anything else)
will be like that... It's just common sense really,
it takes an investment in time to program assembly language, the more
time you give it the better you get however you can't give all your
time into programming it because you have to make a living as well
and if everybody wants you to just patch some C/C++ code....

Anyhow, there were never that many assembly programmers really,
(well decent ones anyhow) even in the good old days ;-) Personally
I think that us, like the Forth people are more interested in
computers *themselves* than most people are or ever were. We want
to know who the things work, exactly what they are doing, how
to control it and make it do what we want, how to be able to know
and explain anything that is going on and research new ideas.... :-)

bestwishes
laura



Thu, 30 Jun 2005 02:08:20 GMT  
 some questions

Quote:

> The instructions I quoted are actually *recommended* by AMD as neutral
> code-fillers when more than 1 byte needs to be skipped.

   May be. Intel and AMD processors have different internal
architecture (even though it may be somehow similar).

   If you look in old Pentium manuals you'll see that NOP takes 1
cycle to execute and pairs in any pipe. Other forms of XCHG don't pair
at all. MOV AX, AX can't pair, for example, with SUB AX, AX. Also on
Pentium (and earlier 486) when a register us written to it cannot be
used for complex addressing until after the next cycle (may be up to 3
instructions on Pentium).

   In P6 instruction to decoder specification you'll also see the
difference: NOP is decoded to one u-op, XCHG - to 3. Apart of affect
on 4:1:1 decoder, when register is written to it allocates a temporary
and impacts register renaming mechanism.

/BP



Thu, 30 Jun 2005 16:52:52 GMT  
 some questions

Quote:


>>Why asm programmers are so few?

>Job security :-)
>                                     If you turn the clock back
>10 years or even just 5 you will see the number of jobs requiring
>it go up exponentially even ( for example you can search googles
>archive in the jobs newsgroups for 'x86' and 'assembly language' )

>Nowadays 95% of positions that want some assembly language only
>state 'assembly language experience *desireable' or 'familiarity
>with assembly language'. That is not really necessarily a good
>litmus test of the way things are going since you do have many
>more jobs now than there were, however if you look at the jobs
>which were traditionally the province of assembly coders only
>you see a sharp decline over the years (games, embedded programming,
>operating systems drivers, although these 3 areas still require
>assembly programmers but not in such numbers and the size of the
>work is being progressively scaled down as they work out how to
>replace more and more functionality with C, C++, Java.... actually
>working on optimised Java Virtual Machines is one area where they
>want *more* assembly coding ability at the moment...

Thank you Laura


Fri, 01 Jul 2005 18:57:07 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Questions-Questions-Questions-Answers-Answers

2. Question(Questions, questions...)

3. Newbie Question: Realbasic Question

4. Questions Questions

5. Questions and more questions...

6. Browse Question / Report question

7. ***Data buffering question. Long post, lots of questions

8. questions, questions!

9. Questions, questions!

10. MicroWorlds Pro "QUESTION Set Size" question

11. OS/2 REXX Question (Object REXX Question Inside)

12. Doc question and Mount question

 

 
Powered by phpBB® Forum Software