flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > High Level Languages > Need help in C (Pointers and References)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Overflowz



Joined: 03 Sep 2010
Posts: 1047
Need help in C (Pointers and References)
Hi, can anybody translate for me from ASM to C how it would be ? Thank you Smile


Code:
1mov eax,[ptr]
2mov ax,word[ptr]
3mov al,byte[ptr]
4mov eax,[ptr]
mov eax,[eax]
.. and so on


Thank you Smile
Post 13 Nov 2012, 15:38
View user's profile Send private message Reply with quote
dancho



Joined: 06 Mar 2011
Posts: 74
There are 2 ways to acces registers by C compiler/linker ( PellesC in this case ), by
1.) inline assembler , or by
2.) separated assembled module linked to main file

so 1.example :

Code:


#include <stdio.h>

int main() {
       
    int temp=0x10;

  __asm 
      {
              mov eax,temp
                mov ax,word[temp]
           mov al,byte[temp]
   }

  return 0;
}






and for the 2.example just assemble asm file as mscoff and link it with main file ,
btw PellesC has assembler too , masm style , try it...
Post 13 Nov 2012, 17:33
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1384
Location: Toronto, Canada
hmmm... I am not sure if you answered the exact question which was asked.
Post 13 Nov 2012, 22:12
View user's profile Send private message Send e-mail Reply with quote
Overflowz



Joined: 03 Sep 2010
Posts: 1047
AsmGuru62 is right, I know already inline ASM, but I need the same syntax in C.
for example (how I imagine code)

Code:
char simple[] = "Apple";
char *sample = *simple;
---
is equal tu mov eax,byte[simple]


I don't understand pointers and references in C..
Post 13 Nov 2012, 22:22
View user's profile Send private message Reply with quote
pabloreda



Joined: 24 Jan 2007
Posts: 76
Location: Argentina
in 32bits compiler (GCC)


Code:

1mov eax,[ptr]

int a,*ptr

a=*ptr;
 
2mov ax,word[ptr

short w;

w=*(short*)ptr

3mov al,byte[ptr

char c;

c=*(char*)ptr



Post 14 Nov 2012, 00:10
View user's profile Send private message Visit poster's website Reply with quote
dancho



Joined: 06 Mar 2011
Posts: 74
uf yeah sorry Overflowz , I overlooked word translate,
my bad...
Post 14 Nov 2012, 08:56
View user's profile Send private message Reply with quote
Overflowz



Joined: 03 Sep 2010
Posts: 1047
Thank you pabloreda, now I understand how it works Smile
@dancho you already gave me useful information, thank you Very Happy
Post 14 Nov 2012, 12:30
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
Also, slight nit-pick: there's no "references" in C, that's a C++ feature... and they behave differently from pointers in syntactical (sugar) as well as functional ways.

And furthermore: you can access, say, *(mypointer + 42) - the offset part is in multiples of the pointer base type, though, and not a simple byte-offset as an assembly programmer would probably expect. It's probably a bit more logical if you realize that "*(mypointer + 42)" is the same as "mypointer[42]".
Post 15 Nov 2012, 00:17
View user's profile Send private message Visit poster's website Reply with quote
farrier



Joined: 26 Aug 2004
Posts: 274
Location: North Central Mississippi

_________________
Some Assembly Required
It's a good day to code!
U.S.Constitution; Bill of Rights; Amendment 1:
... the right of the people peaceably to assemble, ...
The code is dark, and full of errors!
Post 15 Nov 2012, 04:56
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2118
Location: Usono (aka, USA)
To be completely honest, it's a mess. I'm far from a pro, and I definitely don't want to complain about C, it's not so bad, but it's indeed a bit weakly typed (due to various reasons, e.g. heritage from B) and a bit confusing. It makes it harder to write portable code (esp. when type sizes vary across platforms). You have to be very very careful and use limits.h, float.h, inttypes.h, stdint.h, ptrdiff_t, size_t, int32_t, etc.

Part of the problem is also that arrays decay into pointers, which is C's way of avoiding strictly sized arrays (a complain about original Pascal that was fixed in later derivatives). Also, unlike "original" Pascal, C can get/use the absolute address of anything. Hence it's easy to misuse pointers or make sloppy errors. Various add-on utilties and workarounds have been used (cdecl, lint, valgrind, Boehm gc) to avoid such errors.

I wish I had an easy answer, but the simple truth is that you should probably?? avoid pointer arithmetic if at all possible.


Code:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
  static intpointer_to_int = NULL;
  static int moo = 0x5150;

  pointer_to_int = &moo;
  printf("0x%x",*pointer_to_int);
  return EXIT_SUCCESS;
}


Post 25 Nov 2012, 01:56
View user's profile Send private message Visit poster's website Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1217
Location: NC, USA

rugxulo wrote:
I wish I had an easy answer, but the simple truth is that you should probably?? avoid pointer arithmetic if at all possible.

I consider myself sorta a C/C++ expert (at least when I'm given a reference, it's been a while) and I would say that this is very good advice. Just use array syntax.

But, if, for whatever reason, you *need* to do actual pointer arithmetic, use uintptr_t from stdint.h. It's basically a type which can represent a void pointer as an integer, and be cast back to a valid void pointer. Just FYI, void pointers are like the real pointers from ASM, all other pointers behave weirdly to an ASM programmer (except char, but that's only because it happens to be a byte). The reason for uintptr_t is because pointer arithmetic is undefined for void* by the standard. For example:

Code:
void *t = NULL;
t += 1;

As last I tested (a year or two ago), t will be 1 with GCC (as you would expect), but this is implementation defined and actually a deviation from the standard.
Post 30 Dec 2012, 04:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14848
Location: Lost in translation

Tyler wrote:
The reason for uintptr_t is because pointer arithmetic is undefined for void* by the standard. For example:

Code:
void *t = NULL;
t += 1;

As last I tested (a year or two ago), t will be 1 with GCC (as you would expect), but this is implementation defined and actually a deviation from the standard.

Does it make a difference if 0 is used instead of NULL?

Code:
void *t = 0;
t += 1;

Post 30 Dec 2012, 05:01
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1173
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 22:08; edited 1 time in total
Post 30 Dec 2012, 12:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14848
Location: Lost in translation

HaHaAnonymous wrote:

Quote:

Does it make a difference if 0 is used instead of NULL?


Of course no, NULL = 0.

Is this guaranteed by the C specification?
Post 30 Dec 2012, 12:59
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000

revolution wrote:

HaHaAnonymous wrote:

Quote:

Does it make a difference if 0 is used instead of NULL?


Of course no, NULL = 0.

Is this guaranteed by the C specification?


If using windows SDK yes. Otherwise you have to define it somewhere else.

What the op has to know is that pointers are just numbers, holding an address to data in memory
Post 30 Dec 2012, 13:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14848
Location: Lost in translation

typedef wrote:
What the op has to know is that pointers are just numbers, holding an address to data in memory

This might be true for an x86 32-bit or 64-bit CPU but other CPUs do not always have the same widths for addresses and data. The 16-bit x86 CPU in some compilation models has an extra segment register. If you only do computations within addresses then this probably won't be a concern, but once you try to move address pointers to/from data variables things might go wrong.
Post 30 Dec 2012, 13:38
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14848
Location: Lost in translation

typedef wrote:
If using windows SDK yes. Otherwise you have to define it somewhere else.

So is the answer to my question "no"? I don't expect that the Windows SDK defines the C spec, right?
Post 30 Dec 2012, 13:43
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

Tyler wrote:

Code:
void *t = NULL;
t += 1;

As last I tested (a year or two ago), t will be 1 with GCC (as you would expect), but this is implementation defined and actually a deviation from the standard.

Hm, I'd have to dig out The Standard to see if it's actually legal code, but I'd expect at least a big fat warning.

For what it's worth: GCC 4.4.5 compiles without a warning in C mode, but gives "warning: pointer of type 'void *' used in arithmetic" in C++ mode. When run (64bit linux, compiled to 64bit ELF) it indeed produces '1'.

Visual C++ 17.00 (the one from VS2012 + Update 1) I get "void.cpp(5) : error C2036: 'void *' : unknown size" which might be against the spec (which would be bad), but at least is sane Smile


revolution wrote:

HaHaAnonymous wrote:

Quote:
Does it make a difference if 0 is used instead of NULL?


Of course no, NULL = 0.

Is this guaranteed by the C specification?



For C, section 5.4, Address Arithmetic. NULL is defined in stdio.h, and there's nothing special about it, it's just a symbolic define for 0. In C++, because of tighter type checking and how some library vendors defined NULL, it has been better to use literal 0... C++11 has finally introduced "nullptr".

...

IMHO, the way pointers are handled in C/C++ makes sense - most of the time you want to deal with elements rather than memory offsets, and when you need to deal with memory offset you still can do that - but the common case is simpler & shorter. Also, as revolution has touched on, not everybody lives in a flat memory model (and then there's things like structure padding), so it'd be nasty to have portable pointer arithmetic in your code if you were dealing with byte- instead of element-offsets.

Also, even in flat address space programs, not all pointers are necessarily equally wide. C++ member function pointers come to mind Smile

_________________
Image - carpe noctem
Post 30 Dec 2012, 13:59
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
OK, just skimmed through the pointer arithmetic part (ANSI C 2nd. ed.) as well as references to "void" and "void*" (and even threw in "sizeof" for good measure) from the index... and didn't find anything that seemed relevant. IMHO arithmetic on "void*" doesn't make sense, and if one could talk about "the size of nothing" at all, it should at least be 0 and not 1 Smile

EDIT: for C++, it's quite clear:

Quote:
A pointer to any type of object can be assigned to a variable of type void*, a void* can be assigned to another void*, void*s can be compared for equality and inequality, and a void* can be explicitly converted to another type. Other operations would be unsafe because the compiler cannot know what kind of object is really pointed to. Consequently, other operations result in compile-time errors.

Post 30 Dec 2012, 14:22
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
I love C as much as I love Assembly.

nothing wrong with it.
Post 30 Dec 2012, 18:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.