Reading integers from keyboard in Assembly (Linux IA-32 x86 gcc gas)

0
votes

I'd like to know how to read integers from keyboard in assembly. I'm using Linux/x86 IA-32 architecture and GCC/GAS (GNU Assembler). The examples I found so far are for NASM or some other Windows/DOS related compiler.

I heard that it has something to do with the "int 16h" interrupt, but I don't know how it works (does it needs parameters? The result goes to %eax or any of its virtual registers [AX, AH, AL]?).

Thanks in advance, Flayshon.

:D

3
linuxgccassemblyinterruptgnu-assembler
Actually it depends on the environment, i.e. the operating system. The main difference between GAS and NASM (and others) is AT&T vs. Intel syntax which is mostly exchanged positions of source/destination plus some differences for other syntax elements. One is usually still comprehensible to someone knowledgeable in the other, though. – 0xC0000022L
You almost certainly will not be using INT 16h to interface with Linux... – Brian Knoblauch
Why do you want to code in assembly? Are you fluent with Posix/Unix/Linux application-level system programming (i.e. most syscalls)?? – Basile Starynkevitch

3 Answers

2
votes

Simple answer is that you don't read integers from the keyboard, you read characters from the keyboard. You don't print integers to the screen, either - you print characters. You will need routines to convert "ascii-to-integer" and "integer-to-ascii". You can "just call scanf" for the one, and "just call printf" for the other. "scanf" works okay if the user is well-behaved and confines input to characters representing decimal digits, but it's difficult to get rid of any "junk" entered! "printf" isn't too bad.

Although I'm a Nasm user (it works fine for Linux - not really "Windows/dos related"), I might have routines in (G)as syntax lying around. I'll see if I can find 'em if you can't figure it out.

As Brian points out, int 16h is a BIOS interrupt - 16-bit code - and is not useful in Linux.

Best, Frank

0
votes

In 2012, I don't recommend coding an entire program in assembly. Code only the most critical parts (if you absolutely want some assembly code). Compilers are optimizing better than humans. So use C or C++ for low level software, and higher-level languages e.g. Ocaml instead.

On Linux, you need to understand the role of the linux kernel and of system calls, which are documented in the section 2 of man pages. You probably want at least read(2) and write(2) (if only handling stdin and stdout which should have already be opened by the parent process, e.g. a shell), and you probably need many other syscalls (e.g. open(2) and close(2)). Don't forget to do your buffering (for efficiency purpose).

I strongly recommend learning the Linux system interfaces by reading a good book such as Advanced Unix Programming.

How system calls are done at the machine level in assembly is documented in the Linux Assembly Howto (at least for x86 Linux in 32 bits).

0
votes

If your goal is to "obtain" a program, I would agree entirely with Basile. If your goal is to "learn assembly language", these other languages aren't really going to help. If your goal is to learn the nitty-gritty details of the hardware, you probably want assembly language, but Linux (or any other "protected mode" OS) isolates us from the hardware, so you might want to use clunky old DOS or even "write your own OS". Flayshon doesn't actually say what his goal is, but since he's asking here, he's probably interested in assembly language...

Some of us have a mental illness that makes us think it's "fun" to write in assembly language. Humor us!

Best, Frank