Assembly Interupt in C++

This is a discussion on Assembly Interupt in C++ within the C++ Programming forums, part of the General Programming Boards category; I wrote a piece of working assembly code and I am now trying to combine it with a c++ program. ...

  1. #1
    Registered User
    Join Date
    Jun 2007
    Posts
    25

    Assembly Interupt in C++

    I wrote a piece of working assembly code and I am now trying to combine it with a c++ program. I have just figured out that dev-c++ can't handle interupts. How else can I get my assembly code into the c++ program.

    My original assembly code
    Code:
    main:
    mov ax, 09
    mov ds, ax
    mov ax, 0a000h  ;Set ES to be the graphics segment
    mov es, ax
    mov ah, 0Fh  ;Gets and saves current video mode
    int 10h
    push ax
    mov ax, 0013h  ;Turn on mode 13 graphics
    int 10h
     
    mov cx, 320  ;Number of pixels per row/Screen width
    mov ax, 100  ;Set y coordinate
    mul cx
    mov cx, 160  ;set x coordinate
    add ax, cx
    mov bx, ax
    mov cx, 9  ;Set Color
    mov es:[bx], cx  ;Place point
     
     
    mov   ah,0       ;wait for keypress
    int   016h
    pop ax   ;Restore original graphics mode
    mov ah, 0
    int 10h
    mov ax, 4c00h  ;Exit program
    int 21h
    My updated c++ program
    Code:
    void point()
    {
        __asm("mov %ax,_09");
        __asm("mov %ds, %ax");
        __asm("mov %ax, _0a000h");
        __asm("mov %es, %ax");
        __asm("mov %ah, _0Fh");
        __asm("int 10h");
        __asm("push %ax");
        __asm("mov %ax, _0013h");
        __asm("int 10h");
        __asm("mov %cx, _320");
        __asm("mov %ax, _100");
        __asm("mul %cx");
        __asm("mov %cx, _160");
        __asm("add %ax, %cx");
        __asm("mov %bx, %ax");
        __asm("mov %cx, _9");
        __asm("mov %es:[bx], %cx");
        __asm("mov %ah,_0");
        __asm("int 016h");
        __asm("pop %ax");
        __asm("mov %ah, _0");
        __asm("int 10h");
        __asm("mov %ax, _4c00h");
        __asm("int 21h");
    }
    Any Help would be appreciated,
    Steven

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,529
    > I have just figured out that dev-c++ can't handle interupts.
    That would be because it isn't a DOS compiler.
    Which should be fairly obvious, since your OS isn't DOS either.

    Don't make the mistake of assuming that the nice black rectangle you see with a "C:\>" prompt in it is DOS. It isn't, not by a long way.

    What you're creating using dev-c++ are win32 console programs. Consoles don't do graphics, and don't need messy interrupt calls to muck about with specific memory locations.

    If you want to do graphics, then use the package manager to download the "devpak" for libsdl
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Salem View Post
    > I have just figured out that dev-c++ can't handle interupts.
    That would be because it isn't a DOS compiler.
    Which should be fairly obvious, since your OS isn't DOS either.

    Don't make the mistake of assuming that the nice black rectangle you see with a "C:\>" prompt in it is DOS. It isn't, not by a long way.

    What you're creating using dev-c++ are win32 console programs. Consoles don't do graphics, and don't need messy interrupt calls to muck about with specific memory locations.

    If you want to do graphics, then use the package manager to download the "devpak" for libsdl
    Actually, I believe that if you do a 16-bit application, you can convince the DOS shell to go into graphics mode and do all sorts of "wonderful" things. This, however, requires that the code is built for 16-bit mode, which dev-c++ doesn't, and the limit of 640KB of memory is quite a challenge for modern software.

    I'm also pretty sure that 64-bit version of Windows doesn't support any 16-bit apps, and that will be the future versions of Windows - maybe not the next year or two, but certainly not that distant in the future.

    I agree that libsdl or similar is definitely the right solution.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Interupts are a bad thing unless you are specifically writing for real mode. Nowadays the only people that write real mode programs are hobbiests and industrial engineers. Command prompt isnt really dos, its a VM, which emulates dos (poorly). I dotn even know of any 16 bit compilers anymore, last one I had was Turbo C back in the early 90's
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    The DOS emulation in Windows XP is actually rather robust but it will not let you load drivers into high memory, service certain interrupts, or do low level DMA programming (at least without being harassed by the OS). It's also much picker about how you handle memory even while in protected mode which was not true under DOS or extended DOS via DPMI. You could theoretically map an address outside of your address space into your address space using near pointers with no problem. Windows XP barfs when you attempt this in a DOS session.

    As has been suggested use a modern compiler with a modern graphics API.
    Last edited by VirtualAce; 12-12-2007 at 05:47 PM.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by abachler View Post
    Interupts are a bad thing unless you are specifically writing for real mode.
    Because more advanced operating systems don't use interrupts? I think there's a break in your logic there.

    In a modern OS it is unusual for a user application to install an interrupt handler but it's not like there aren't any interrupts going on.

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by brewbuck View Post
    Because more advanced operating systems don't use interrupts? I think there's a break in your logic there.

    In a modern OS it is unusual for a user application to install an interrupt handler but it's not like there aren't any interrupts going on.
    There are of course two aspects of this. Yes, HARDWARE interrupts are DEFINITELY going on in ANY system (at least anything more complex than a very basic electronic toy).

    Software interrupts, like in the above code, is also used quite often to do system calls [in Windows, Linux, OS/2 and most of the RTOS's I've seen the source for].

    However, I think abachler's point is that the programmer rarely, if ever, use these software interrupt him-/herself, because they are part of the low-level runtime library functions, and it's fairly well hidden and separated from the application programmer - and so it should be. There are for example things like SYSCALL/SYSENTER that got introduced to recent x86 processors, that allow a faster entry into the kernel than INT xx instructions. If you replace one with the other, then the application software gets affected. That's not very good for the application software. If the application software is actually using the system calls directly, then that means binary compatibility is broken when an upgrade of the OS happens - not a good idea.

    So, I agree in the principle that calling Software interrupts inside application code is broken.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Software interrupts have been replaced by calls to drivers who then perform the low-level functionality you need. This is the way Intel designed protected mode to work according to the tech refs and I believe there is even a whole section in the books about this very topic.

    The idea from a software level is that now instead of having to call BIOS, hook interrupts, etc, etc, we call drivers in the operating system which then handle the nitty gritty that most of us could care less about. If I'm an application needing low level access to the hard drive I really don't care how it gets done or the process involved. All I know is a driver in memory should be able to handle all of that junk and the outcome is I gain low level access to the hard drive. Windows does this by providing the DDK and by allowing users to install drivers which then get called by the OS to perform their specific tasks.

    Thankfully the days of loading registers and doing an interrupt are over. Now if I'm in Direct3D and want a 32-bit 1024x768 screen I simply ask for it and the driver either tells me you are crazy we don't support that or it does what I want. I could care less how it does that......I just care that it does it.
    Last edited by VirtualAce; 12-13-2007 at 07:05 PM.

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Bubba View Post
    Software interrupts have been replaced by calls to drivers who then perform the low-level functionality you need. This is the way Intel designed protected mode to work according to the tech refs and I believe there is even a whole section in the books about this very topic.
    The method suggested by Intel, using call-gates, is actually not used very much. Most OS's that I know of use software interrupts or the relevant SYSCALL or SYSENTER instruction. Windows and Linux certainly does. I ported one OS to x86, and that used call-gates. But that is the only semi-commercially available product I know of that uses this technique. I think OS/2 may also do that - not sure.

    So, although you use drivers to do hardware interaction from the user-mode app, it still has to enter the OS, and that's commonly done by Software Interrupt - many of the non-x86 processors also have no other way to enter the OS [e.g. PDP-11, VAX and 68K uses TRAP, 29K uses the "assert" instruction ("ASNEQ", assert not equal, with the same register on both sides, to be precise), ARM uses the SWI instruction - don't know details of any other processors].


    The idea from a software level is that now instead of having to call BIOS, hook interrupts, etc, etc, we call drivers in the operating system which then handle the nitty gritty that most of us could care less about. If I'm an application needing low level access to the hard drive I really don't care how it gets done or the process involved. All I know is a driver in memory should be able to handle all of that junk and the outcome is I gain low level access to the hard drive. Windows does this by providing the DDK and by allowing users to install drivers which then get called by the OS to perform their specific tasks.

    Thankfully the days of loading registers and doing an interrupt are over. Now if I'm in Direct3D and want a 32-bit 1024x768 screen I simply ask for it and the driver either tells me you are crazy we don't support that or it does what I want. I could care less how it does that......I just care that it does it.
    Yes, software drivers is a much better approach than BIOS calls, that's for sure. And supporting multiple devices is much easier when the entry point to a driver is defined as a function pointer in a data-structure that there can be multiples of than when there is one INT XX entry that handles ALL disk drives, for example.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Registered User
    Join Date
    Jun 2007
    Posts
    25
    Thanks. Moving on.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Learning Assembly
    By mrafcho001 in forum Tech Board
    Replies: 5
    Last Post: 03-12-2006, 04:00 PM
  2. C to assembly interface
    By Roaring_Tiger in forum C Programming
    Replies: 4
    Last Post: 02-04-2005, 02:51 PM
  3. assembly language...the best tool for game programming?
    By silk.odyssey in forum Game Programming
    Replies: 50
    Last Post: 06-22-2004, 01:11 PM
  4. True ASM vs. Fake ASM ????
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 04-02-2003, 03:28 AM
  5. C,C++,Perl,Java
    By brusli in forum C Programming
    Replies: 9
    Last Post: 12-31-2001, 02:35 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21