--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00009Date: 05/15/98 From: JOS CROEZE Time: 03:08am \/To: ADAM MAJER (Read 2 times) Subj: NOP Hello Adam, AM> I've got a very simple but puzzling (to me) question. Why is there a AM> NOP instruction? Doesn't it just waist time? And, where should it be AM> used if it's useful at all? Thanx in advance for any answers that I AM> might get. The only waste of time I can think of is for the processor reading the opcode. Since the NOP-instruction exists out of 1 byte, it can be usefull for lazy assembler-builders for JMP-opcodes followed by 1 or 2 bytes. Greetings, Jos Croeze --- Dutchie V3.04 * Origin: HCC Groningen-1 (lijn 2) (2:500/19) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00010Date: 05/15/98 From: ED BEROSET Time: 07:09pm \/To: ALL (Read 2 times) Subj: Re: Ide "Sleep" Mode From: Ed Beroset Reply-To: 80xxx@circuit.com At 20:23 5/13/98, you wrote: >>(Also, OSs such as W95 and OS/2 ignore the BIOS anyway. It gets swapped >>out when the OS runs, and it never executes anything again.) > >EB>While it's true that many of the BIOS services are no longer used, >EB>many are essential to operating systems like Windows 95 and OS/2. > >Actually, they aren't important to OS/2. It requires p-mode drivers or >p-mode, IOPL-enabled DLL's for everything hardware related. There is no >r-mode execution under OS/2 (or NT). It's certainly true that much of the BIOS, being real mode services, is unused by protected mode operating systems. However, the BIOS services I mentioned are not exclusively real mode. In fact, they provide 32-bit protected mode services intended for use in just such operating systems as OS/2, NT, and Linux which do not use real mode once they're up and running. >EB>These include Advanced Power Management functions, 32-bit PCI >EB>interface, and Plug-and-Play services. Because these functions exist >EB>with the BIOS within the ROM space (I call it BIOS too, but it's >EB>really more than BIOS) I think you'll find that the BIOS is rarely >EB>swapped out. > >On many systems, the RAM copy of the BIOS is overwritten by OS/2, and >restored from ROM when it shuts down. The BIOS is replaced, unless one very >special device driver requests it remain. I know of nobody who still uses >that driver. I don't dispute what you say, but it makes me wonder -- how does OS/2 support APM and PCI, since both typically rely on BIOS services? I don't use OS/2 any more, but when I ran it, I recall that that OS did support some form of APM -- my recollection is APM version 1.0. If that's the case, it would have to do so by either dropping into real mode or by calling the protected mode services of the BIOS. I'd guess they don't drop into real mode. Back in the APM 1.0 days, protected mode support in the BIOS was only "strongly recommended" but as of version 1.2 and beyond, it's required. It's pretty much the same story for PCI services. It has been a long time since I ran OS/2, but my recollection is that while the BIOS was indeed replaced, it retained large portions of the original -- only a few bytes were changed. In other words, it was a slightly modified RAM copy of the runtime BIOS ROM, but not a complete rewrite. OTOH, my gray-cell memory unit frequently experiences parity errors, so perhaps someone with a currently running OS/2 box could check this out. Basically, the test would be to boot up in real mode (e.g. plain DOS diskette) and then use a small assembly language program to save the E000h and F000h segments to a 128K file. Then boot up into the operating system and do the same thing from within the command shell. I'm certain they will be different (they even differ under Win 3.1) but I think the differences will be relatively small and localized. Would that be something you'd be willing and able to check? Here's some quick and dirty code to help do that test. A useful cross-check might be to write and run a native OS/2 version of the same program. -+--- savebios.asm begins ; savebios.asm ; ; This is a quick & dirty DOS program which saves the BIOS ROM area ; from E0000h through FFFFFh to a 132K disk file named "bios.bin" ; ; written on Fri 05-15-1998 by Edward J. Beroset ; and released to the public domain by the author ; .model tiny .code org 100h Start: mov di,offset errmsg1 ; xor cx,cx ; regular file mov dx,offset filespec ; mov ah,3ch ; create file int 21h ; create the file jc Error ; mov di,offset errmsg2 ; mov bx,ax ; put file handle where we need it mov dx,0e000h ; point to beginning of segment mov cx,8000h ; write 32k at a time nextchunk: mov ds,dx ; xor dx,dx ; mov ah,40h ; write using handle int 21h ; jc Error ; mov dx,ds ; are we done? cmp dh,0f8h ; jz done ; add dh,08h ; jmp nextchunk ; done: mov ah,3eh ; close file int 21h ; mov ax,4c00h ; return to DOS int 21h ; Error: mov bx,2 ; write to stderr mov dx,cs ; point to our data segment mov ds,dx ; xor cx,cx ; mov cl,[di] ; mov dx,di ; inc dx ; adjust pointer mov ah,40h ; write using handle int 21h ; mov ah,4ch ; int 21h ; filespec db "bios.bin",0 errmsg1 db msg1len, "Error opening file",13,10 msg1len = $-errmsg1 errmsg2 db msg2len, "Error writing file",13,10 msg2len = $-errmsg2 end Start -+--- savebios.asm ends For what it's worth, when I perform that test under Win95, a binary file compare shows just seven bytes differ. I'd be curious to find out how many differ under OS/2 -- I'll bet it's about the same. Ed --- * Origin: The Circuit! Board * Spokane * (1:346/100) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00011Date: 05/14/98 From: AUKE REITSMA Time: 10:35pm \/To: ADAM MAJER (Read 2 times) Subj: NOP Hi Adam, On 13 May 98, 15:58, you wrote to All AM> I've got a very simple but puzzling (to me) question. Why is AM> there a NOP instruction? Doesn't it just waist time? And, where AM> should it be used if it's useful at all? Thanx in advance for any AM> answers that I might get. 1 - Yes, it just wastes time. (I wish I were allowed to do that ccasionally.) Sometimes that wasting is (or rather: used to be) useful. 2 - Sometimes some padding is required in the code. E.g. 'primitive' assemblers might initially code jumps as a three byte code. Ultimately changing it to a two byte code and a NOP where possible. 3 - NOP is just "xchg ax, ax" iirc. getting rid of it entirely takes _extra_ stuff. Greetings from _____ /_|__| Auke Reitsma, Delft, The Netherlands. / | \ -------------------------------------- --- GEcho 1.00 * Origin: Home by the C (Auke.Reitsma@net.hcc.nl) (2:281/400.20) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00012Date: 05/15/98 From: JASEN BETTS Time: 05:40pm \/To: SAM IZZO (Read 2 times) Subj: image booting SI> So maybe you should restore all interrupt vectors, just in case. SI> Actually, anyone know why exactly it would crash if interrupt vectors SI> haven't been restored? you've got, for instance a clock-tsr running, dos reboots and begins loading stuff to arbitrary memory locations as it boots, all of a sudden something overwrites the memory used by the TSR, next time the timer ticks it's bye-bye. while DOS is booting the memory allocation scheme is disabled/ignored. SI> Anyone know why I can't step into int 19h in Turbo Debugger? how far do you get? Where it the debugger loaded, are you running XMS?, is the 32nd kilobyte ree? --- EzyQwk V1.20 01fa018d * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00013Date: 05/15/98 From: JASEN BETTS Time: 05:46pm \/To: ADAM MAJER (Read 2 times) Subj: NOP AM> I've got a very simple but puzzling (to me) question. Why is there a AM> NOP instruction? it's handy if you want to patch an executable to disable a certain feature. AM> Doesn't it just waist time? yeah, that's what it's for. AM> And, where should it be used if it's useful at all? It's also useful in self-modifying code. or if you want to leave a "unused" protion that can be later patched to add features. --- EzyQwk V1.20 01fa018d * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00014Date: 05/15/98 From: JASEN BETTS Time: 04:39pm \/To: DOUG NEWMAN (Read 2 times) Subj: system timer DN> k8342410. A dump of memory reports P. Rom Rev 1.03 8/24/88 DN>Copyright Seiko Epson. 1988. OK.... I guess that's a start Seiko-Epson, now that was a brand name, and brand name machines are non-standard. (seems kinda backwards eh?) DN>The clock calendar chip is not a Motorla as I said but still DN>is a 146818. I think that these were a common "Cmos" of the DN>time but not common for XT class machines. 146818 - so it's got an AT type timer chip.... that means all the XT port adresses I have just extracted are no use... 0070-007F ---- CMOS RAM/RTC (Real Time Clock MC146818) I guess those addresses won't work if the AT utilities didn't help you. I'll have another look and see what I can find. NOTHING.... AAARGH... unless you've got a logic probe and pinouts of the RTC chip I can't think of a good way to figure out it's address. Bye. --- EzyQwk V1.20 01fa018d * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00015Date: 05/15/98 From: TIM HUTZLER Time: 11:37pm \/To: ADAM MAJER (Read 2 times) Subj: Re: NOP -=>Quoting Adam Majer to All <=- AM>I've got a very simple but puzzling (to me) question. Why is there a AM>NOP instruction? Doesn't it just waist time? And, where should it be AM>used if it's useful at all? Thanx in advance for any answers that I AM>might get. AM>Happy coding, AM>Adam Majer Hi Adam; There are two very useful places where one would use a NOP. One is to simply provide a delay in the code. You can find some examples of this in code using the IN and OUT instructions, especially in regards to programming COM ports. Another place is in patching code. When replacing a shorter snippet of code over a larger section, the difference can be padded with a few NOPs so the CPU will not stumble over it. Of course, anything more than three NOPs should have a JMP. --- Maximus/2 3.01 * Origin: Madman BBS * Chico, California * 530-893-8079 * (1:119/88) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00016Date: 05/15/98 From: BRYAN SCHWARTZ Time: 09:59am \/To: ANTHONY TIBBS (Read 2 times) Subj: OS/2 serial port According to "OS/2 2.0 Control Program Programming Guide" page 14-1 to 14-5, to access the serial ports under OS/2 you have to use the API DosDevIOCtl It has an example of writing contents to a disk file to the COM1 Serial Port, but it's in "C", as are all the other examples of how to use DosDevIOCtl. The Data Structure "LINECONTROL" is used to set the characteristics of a COM port through the IOCtl interface. page 14-8 I couldn't find anything on serial port programming for OS/2 in assembler. This is an old book...1992 ISBN 1-56529-154-9 published by QUE --- QScan/PCB v1.17b / 01-0105 * Origin: 1:348/206 Muddy Waters 204-231-4507 (1:348/206) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F5W00017Date: 05/17/98 From: ADAM MAJER Time: 10:59am \/To: BAYANI CUSTODIO (Read 2 times) Subj: NOP BC>That is the biggie and you just answered yourself... Yes, waste time BC>especially if you are doing a timing loop when you want the system to BC>keep doing nothing. You just perform enough loops with NOP to waste BC>however much time you require to waste. Then why isn't this instruction the same for every processor. Up to 386 it takes 3 clock cycles for execution but starting from a 486 processor, it only takes 1 clock cycle. Why? * SLMR 2.1a * --T-A+G-L-I+N-E--+M-E-A+S-U-R+I-N-G+--G-A+U-G-E-- --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203)