Recent Posts

11

Programming with NASM / Re: fgets, gets, scanf

« Last post by iAnzu on June 01, 2019, 09:02:14 PM »

Something I came up with is, since I know the length of the string to be entered, I know where the "null" character will be (with gets), therefore, I just check if the null character is added , if not, I ask again for the string. 

This auxiliar buffer's length is 123 bytes, so if the user enters more than that, the program will break... but at least is more serviceable! I think

12

Programming with NASM / fgets, gets, scanf

« Last post by iAnzu on June 01, 2019, 05:00:51 PM »

Hi,

I'm doing a little nasmx86 program, and at many places I need to get user input, with an specified length.
I'm using Linux  and building as:
nasm -f elf32 -o
gcc  -m32 -o

I would like to know if the user entered more/less than the expected, in which case I would like to clear stdin, and tell the user to try again.


gets:
The problem with this, is I can't control how much input the user will enter, I'm using gets, and then copying "n" bytes to another string, so if I want a 5 char name, and the user enters "123456", it won't cause any problem, because, gets has a large reserved memory to allocate it, then I copy the first 5 bytes to another place and it's done. But it doesn't look good visually.

scanf:
Using special arguments ("%3s") solves the problem, but if the user entered more than the allowed digits, those digits will stay in stdin, and will be used when there's a new call that uses stdin.

fgets:
Same problem with scanf...

I've tried...
- For the case of fgets, and scanf, if the user entered more than the allowed digits I can do a dummy call to gets, to flush stdin, but if the user entered less than the allowed digits, the dummy call to gets is useless, and will make the program ask for non required additional input.

13

Example Code / Re: nasm or SASM?

« Last post by Jenneferhart on May 29, 2019, 12:09:38 AM »

Thanks everybody. I used the "syscall" method.

                                                           Jenn

14

Example Code / Re: nasm or SASM?

« Last post by fredericopissarra on May 28, 2019, 05:18:17 PM »

The way a process terminates depends on the operating system. On Linux, in amd64 version, you can use the syscall instruction to invoke calls to the kernel (system calls). One of them is equivalent to C's exit() function:

Code: [Select]

  mov eax,60  ; 60 is the code for exit().
  mov edi,0  ; 0 on EDI is the code passed to exit().
  syscall  ; finally calls exit(0) - ending the processBut, if you are using Linux, 32 bits version, the syscall instruction isn't present. You must use int 0x80 interface to do system calls. The equivalent from above is:

Code: [Select]

  mov eax,1  ; 1 is the code for exit().
  mov ebx,0  ; 0 on EBX is the code to pass to exit().
  int 0x80  ; calls exit(0), ending the processNotice the codes are different for amd64 and i386 linuxes...
I don't know how to do for Windows Desktop Applications, except the old DOS way:

Code: [Select]

  mov ax,0x4c00  ; 0x4C is exit; 0x00 is the errorlevel.
  int 0x21
If you disassemble a code created by a C compiler, you'll see a RET instruction in the end of the main() funcion. It is this way because main() is called by the "runtime" object file linked to your program without you knowing... this runtime will call main() and exit your process when main() returns (doing some housekeeping like closing all files, freeing memory, etc)...

15

Example Code / nasm or SASM?

« Last post by Jenneferhart on May 28, 2019, 04:26:59 PM »

Hi:
I am new to Assembly Programming. I use nasm & SASM. I have one simple question: (1) In nasm, the end of a Program is with two instructions and a "syscall", (2) SASM has zero out RAX register & then a "ret" instruction. Who is correct?

16

Programming with NASM / Re: Segmentation fault question

« Last post by azagaros on May 27, 2019, 10:24:38 PM »

Debs, all languages boil down to the machine language on any processor.   5 of them have been the most common I have been programming for 30 years.  All other languages have the same basic logic to them and if one can pick up on the syntax of the language, one pick out the common struct to all of them because of the machine language concept.  It is like I can read lisp but cannot program in it.  The concepts from 8086 or 6502 or the 68000 from various companies follow similar constructs of machine language.  Even the current forms of arm V follow simple abstracts of those earlier ones. It is like the simple move from memory to register is common to all of them.

17

Programming with NASM / Re: Segmentation fault question

« Last post by fredericopissarra on May 27, 2019, 09:56:16 PM »

By the way... I have almost 40 years of software development AND electronics experience, not only with assembly (of more than a dozen of processors), but lots of high level languages as well...

You're welcome.

18

Programming with NASM / Re: Segmentation fault question

« Last post by fredericopissarra on May 27, 2019, 09:53:21 PM »

Intel IA-32 and Intel64 Software Development Manual - Vol I - Chapter 3, Topic 3.4.1.1 (General Purpose Registers in 64 bits mode):

"When in 64-bit mode, operand size determines the number of valid bits in the destination general-purpose
register:
...
* 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose
register."

AMD64 Architecture Programmer’s Manual Volume 1 - Application Programming - Chapter 3, Topic 3.1.2 (64-Bit Mode Registers), Figure 3-3 and 3-4... Topic 3.1.2.3 explains...

19

Programming with NASM / Re: Segmentation fault question

« Last post by debs3759 on May 27, 2019, 09:47:53 PM »

azagaros, please do not insult someone who is trying to help you. You may know several programming languages, but that does not mean you know all languages. Higher lever languages do much of the work for you, so you don't need to know as much in order to use them. I have never tried programming in 64-bit code, but fredericopissarra appears to have done so. As he says, the Intel/AMD documentation gives much more info than those who work on nasm, who used that info to write an app which follows Intel assembly coding conventions. Our documentation will never be as complete as that you can get (or maybe have) from Intel.

20

Programming with NASM / Re: Segmentation fault question

« Last post by azagaros on May 27, 2019, 09:30:57 PM »

Gee your stupidity again.  I have 5 programming languages under my belt.   I have read the books you dumb a**.  From every piece of documentation of registers:
|  32 | 16 | 16|  rax is the full 64 and eax is the bottom 32 and ax is then set of 16 is the last set.  rax is 8 bytes eax 4.  Adding the two should look and act like for furthest right bit goes first and cycles to the left. if it overflows the 64 bit it will pop the carry flag. Endian just changes the direction of the cycling goes through. This has not changed in 30 years of x86 class processors.  I think arm processors do it the same way.  It is the way the transistors are put in sequence.  Clearing of the register is left up to the programmer and most bios leave them empty when they start an os. Did you not learn how to add two numbers early in your life?  2's complement follows same logic if you have ever did the math by hand.  You start at the zero bit and go to max bit and Big and little endian determine where the 0 bit is. 

Since I know that impling a register in nasm, does not guarantee the size of the register.  If you want the smallest code concept, it is in the preamble on any integer or pointer; by sequence of any command.  In code generation, by both the AMD and intel documentation, you have the byte code of command, then, depending on command, is the scaler on a number and the bytes that make up the number.  All address space is pointers, which are all integers.   In nasm could take a 64 bit pointer and inadvertently make it a 16 bit pointer, if the value was under 2^16.  A 16 bit number has no scaler and is only 2 bytes for the number,  a 32 has 2 byte scaler with 4 bytes to the number and 64 has a 3 byte scaler and 8 bytes to the number.  There is a lot of space saving in this concept. it also argues the byte concept of the command

One thing that is in AS-- gcc's assembler. It has a denotation to imply which state of command you use. For example mov, movw, movq, mov is the 8 bit/16 bit concept, and movw is the 32 bit concept and movq is the 64 bit concept.