VBCC POSIX Library and 68020 Instructions

[tygre]

Indeed, I'm using 0.9h too
Great, and fast, compiler!

[phx]

Originally Posted by tygre

#define GLOBALS_TASK_STACK_SIZE            65535

Arrrgh!
Ok, I admit vbcc's startup-code doesn't check that the new stack size is even. But I refuse to add extra code for something which everybody should know. An unaligned stack is deadly!

[tygre]

Lesson learned

But then, later in my code, there's another statement that causes a Guru 8000 0003 only on 68000. I don't know how to explain it, although I could fix it:

had = (struct in_addr *)he->h_addr;
ina = *(had); // This dereference causes a Guru 8000 0003 
tmp = inet_ntoa(ina);
addr.sin_addr.s_addr = inet_addr(tmp);

Would you have some idea why this particular statement crashes?

One solution is to replace all this code simply with:

memcpy(&addr.sin_addr, he->h_addr, he->h_length);

Cheers!

[phx]

Originally Posted by tygre

had = (struct in_addr *)he->h_addr;
ina = *(had); // This dereference causes a Guru 8000 0003 
tmp = inet_ntoa(ina);
addr.sin_addr.s_addr = inet_addr(tmp);

Would you have some idea why this particular statement crashes?

I assume that

he

points to a

struct hostent

? Then

h_addr

is a

char

pointer, which is allowed to point to an odd address.
You cast that to a

struct in_addr

pointer, which is a structure with one 32-bit unsigned longword. Therefore dereferencing

had

lets the compiler assume it can copy a 32-bit word, which causes an alignment exception when its address is odd.

[tygre]

Sorry for the lack of details: yes, you're right, he is a struct hostent.

Thanks for the explanation!

I had copied/pasted this code from diverse sources on the Internet, and it seems(ed) legit. For my own education, how could I make it work? How could I "align" he->h_addr so that it points always to an even address? (Is that even possible?)

[phx]

Originally Posted by tygre

I had copied/pasted this code from diverse sources on the Internet, and it seems(ed) legit.

No. It is not. You cannot cast any

char

-pointer to an

int

-pointer and expect to be able to read an

int

from it, without running into alignment exceptions on certain architectures.

The problem is that such an alignment exception will not happen on x86 hosts, so most people never realise they are writing bad code. That's comparable to people depending on specific compiler extensions and think other compilers are broken because they strictly follow the ISO-C standard.

It's always good to compile a source with different compilers and build it for different architectures to find all issues.

For my own education, how could I make it work? How could I "align" he->h_addr so that it points always to an even address? (Is that even possible?)

I rarely do network coding, but I would assume that

h_addr

points to a private buffer of the TCP/IP stack. You have no influence on its alignment. It is recommended to copy the address with

memcpy()

to an

in_addr

structure. Then you can depend on proper alignment.

BTW, some compilers (including vbcc) recognise certain clib functions, like memcpy, and replace them with optimised inline code. So your memcpy-call might be translated into four inline byte-copies.

[tygre]

Hi Phx!

Originally Posted by phx

No. It is not. You cannot cast any

char

-pointer to an

int

-pointer and expect to be able to read an

int

from it, without running into alignment exceptions on certain architectures.

The problem is that such an alignment exception will not happen on x86 hosts, so most people never realise they are writing bad code. That's comparable to people depending on specific compiler extensions and think other compilers are broken because they strictly follow the ISO-C standard.

It's always good to compile a source with different compilers and build it for different architectures to find all issues.

Ah, thanks for your explanations!

Actually, at one point I also compiled my code with SAS/C and I had to change my code a bit to make both VBCC and SAS/C happy
I should try that again one of these days...

Originally Posted by phx

I rarely do network coding, but I would assume that

h_addr

points to a private buffer of the TCP/IP stack. You have no influence on its alignment. It is recommended to copy the address with

memcpy()

to an

in_addr

structure. Then you can depend on proper alignment.

So by memcpy'ing the structure, I'm guaranteed to have a proper alignment? Because when I declare the receiving structure, it's guaranteed to be at an even address?

Originally Posted by phx

BTW, some compilers (including vbcc) recognise certain clib functions, like memcpy, and replace them with optimised inline code. So your memcpy-call might be translated into four inline byte-copies.

Thanks!

[phx]

Originally Posted by tygre

So by memcpy'ing the structure, I'm guaranteed to have a proper alignment?

No. By using memcpy you can ignore the alignment, because memcpy automatically uses the best method to copy the data and takes care of that.

Because when I declare the receiving structure, it's guaranteed to be at an even address?

It depends on the type of the object. When you write to a 16- or 32-bit object you can be sure that an m68k compiler aligned it at an even address.

In the case of

struct in_addr

it is defined as:

struct in_addr {
        in_addr_t s_addr;
}

with

in_addr_t

being an

uint32_t

.

[Thomas Richter]

Originally Posted by tygre

So by memcpy'ing the structure, I'm guaranteed to have a proper alignment? Because when I declare the receiving structure, it's guaranteed to be at an even address?

Err... If you create an object with either automatic or static lifetime, the C compiler of course ensures that the object (and its members) are aligned properly. Also, "memcpy" copies byte arrays, and thus alignment for "memcpy" does not matter. However, the issue is that objects (e.g. "structures") that arrive over the network (or some other external source) are aligned or structured according to the host system's requirements. That is, if the "byte array" that is input to memcpy() does not reassemble a structure as laid out by the host system, then memcpy() cannot ensure that either. Long story short, you cannot exchange objects ("structures") reliably between systems by just copying their memory layout, and coying stuctures 1-to-1 on disk or over the network will in general not work. You will need to define (or use an already defined) "serialization" of such objects. In general, all you can write to disk or transmit over the network are "bytes", and "serialization" defines then how to split up objects into bytes, and how to put bytes back into objects.

[alkis]

if you want to read a long from char *, you can do something like that:

#include <stdio.h>

#define GetLongFromCharStar(x)                                                 \
  (((long)(*x++)) << 24L | ((long)(*x++)) << 16L | (*x++) << 8 | (*x++))

int main(int argc, char const *argv[]) {
  char foo[] = {0x01, 0x02, 0x03, 0x04, 0x05};

  char *p = foo;
  if (((int)p & 1) == 0)
    ++p;

  // int l = *((int *)p);               // this bombs
  int l = GetLongFromCharStar(p); // this does not bomb
  printf("%d (%08X) - Address: %08X\n", l, l, p);
  return 0;
}

[tygre]

Hi Phx, Thomas, and Alkis!

Thank you so much for your explanations and help! Very much appreciated!
Now, this part of my code works fine, but there seems to be another problem elsewhere on Leof's config. I'll track it down...

Cheers!

[vbc]

Originally Posted by alkis

if you want to read a long from char *, you can do something like that:

#define GetLongFromCharStar(x)                                                 \
  (((long)(*x++)) << 24L | ((long)(*x++)) << 16L | (*x++) << 8 | (*x++))

This is wrong in many ways. It causes undefined behaviour due to multiple increments of x without a sequence-point. Also, any byte with bit 7 set will clobber the result due to sign-extension.

[alkis]

Originally Posted by vbc

This is wrong in many ways. It causes undefined behaviour due to multiple increments of x without a sequence-point. Also, any byte with bit 7 set will clobber the result due to sign-extension.

How about this?

#define GetLongFromCharStar(x)                                                 \
  (((ULONG)(*(UBYTE *)x)) << 24L | ((ULONG)(*(UBYTE *)(x + 1))) << 16L |       \
   ((ULONG)(*(UBYTE *)(x + 2))) << 8 | ((ULONG)(*(UBYTE *)(x + 3))))

[vbc]

Originally Posted by alkis

How about this?

#define GetLongFromCharStar(x)                                                 \
  (((ULONG)(*(UBYTE *)x)) << 24L | ((ULONG)(*(UBYTE *)(x + 1))) << 16L |       \
   ((ULONG)(*(UBYTE *)(x + 2))) << 8 | ((ULONG)(*(UBYTE *)(x + 3))))

Yes, that looks good.

[tygre]

PS. BTW, that my code worked on 68020+, was it just by chance or is there something with 68020+ processors that allowed it to work?

[hooverphonique]

Originally Posted by tygre

PS. BTW, that my code worked on 68020+, was it just by chance or is there something with 68020+ processors that allowed it to work?

68020+ allows access to words and longs also at odd addresses, although with a performance penalty.

[tygre]

Thanks HooverPhonique!