RE: [lwip-users] Problem - Using 32-Bit Compilers

[Tamas Somogyi]

Mike, Jifl et all,

We need separate methods for get/set, because those are different -
unless you can decide by the address of in/outptr whether aligned or
not. But the concept of moving the platform-dependent copy code to
sys_arch is a good idea.

There is an other technique: using "access" pointers:
#define get_access(struct_type, p, q) \
   #ifndef struct_type##_load_from_stream \
        struct_type* q = p; \
   #else \
      struct_type _q;
      struct_type* q = &_q; \
      struct_type##_load_from_stream(p, q); \
   #endif

#define commit_access(struct_type, q, p) \
   #ifndef struct_type##_store_to_stream \
        \
   #else \
      struct_type##_store_to_stream(p, q); \
   #endif

Sample code:
/* get access to the structure */
get_access(dns_answer, pchBuffer, s);
/* use 's' as a usual pointer to dns_answer */
if (s->type == 0) ...
  s->class = 23;
/* call commit only if there were any modification (in case of non-const
access) */
commit_access(dns_answer, pchBuffer, s);

Definition of struct_type_load_from_stream and
struct_type_store_to_stream can go to sys_arch as Mike suggested.

This way there's nearly no performance impact for the "sane systems".

I admit that it needs a bit more code, but the code won't be more
complex as this technique requires structured programming approach.

Final remark: our "not-so-sane" compiler fulfills the standard C/C++
requirements. As "direct byte-stream access" is a really important
condition for LwIP, ideally it should be defined in a requirement
specification, and published, so we can more successfully force TI to
support it if it widely used by other systems or other sw packages.

Best regards,
Tamas
 

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Michael Williamson
Sent: 29 August 2008 13:09
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers


> As I said in a mail last night: "A compromise might be to define
> offsets of members, and SMEMCPY from the correct location. An
> optimising compiler can more easily eliminate that and convert to an
> assignment where it knows it can. The situation for those using poor
> compilers could be bad though - function calls every time; and they
> may have been unaffected by the portability issue in the first place.
"
>
> In other words, the price of complete portability would be poor
> performance for the vast majority of existing users. And more complex
> code.
>
> Jifl

What if you made a macro that basically did structure copying as it is
done now, but allowed it to be overridden in a sys_arch.h file?  Not
sure this would work, I'm not a coding wizard, but what about:

#define STRUCT_COPY(struct_type, inptr, outptr) \
#ifndef STRUCT_COPY_##struct_type \
memcpy(outptr, input, sizeof(struct_type)); \
#else \
STRUCT_COPY_##struct_type(inptr,outptr); \
#endif

Then guys with address-alignment challenged compilers could deal with a
non-efficient routine when they needed to and everyone else would get
the optimal solution.  Not sure if this solves the whole problem
(pointer assignment?), but you get the idea....

-Mike