Intel & big endianness - Page 1
Forum section: electronics / general

author: RayJones
author_rank: Frequent Contributor
timestamp: December 09, 2010, 03:14:38 am
content: Considering the vast majority of applications these days that are leveraging network comms in some manner, it surprises me that Intel have not provided an internal mechanism to efficiently convert the big endian values received from a network into their internal little endian format.There must be millions of "wasted" cycles taking place every day to perform the routine mask and shift that takes place within the various forms of hton / ntoh functions.Perhaps it is just me being anal about CPU efficiency but it is such a common operation, and why a simple read write to a special register cannot be used instead of the typically used code below (and confirmed as Visual Studio 10s' equivalent ASM output for htonl):out = (in & 0xff000000) >> 24 |(in & 0x00ff0000) >> 8 |(in & 0x0000ff00) << 8 |(in & 0x000000ff) << 24;

author: the_raptor
author_rank: Regular Contributor
timestamp: December 09, 2010, 04:21:32 am
content: Are you sure compilers aren't using auto-optimisation to access this feature or that the current pipe-lining technology doesn't make this as close to efficient as possible?And honestly modern processors run at around 10-20% for "average" user loads, so this isn't an issue for consumer CPU's. In industry I would expect this sort of thing to be handled in the network interface card.

author: ziq8tsi
author_rank: Regular Contributor
timestamp: December 09, 2010, 05:02:33 am
content: Quote from: RayJones on December 09, 2010, 03:14:38 amintel introduced the "bswap" instruction with the 80486. gcc/glibc htonl uses this unconditionally for x64. for x32, depending on your selection for -march, it may generate either:bswap %eaxor:rorw $8, %ax;rorl $16, %eax;rorw $8, %axdo you have vs configured to output code that will work on a 386?

author: RayJones
author_rank: Frequent Contributor
timestamp: December 09, 2010, 06:47:16 am
content: hey guys that is indeed good to hear.I will try some of the optimisation options.I usually run with these turned off as single step debugging can become a nightmare with code optimisation on.To put this in context I need to pump MB's / second - yes MB's and foolish byte shuffling is wasting time on that volume of data.

author: RayJones
author_rank: Frequent Contributor
timestamp: December 09, 2010, 07:01:15 am
content: LOL, just found this:http://connect.microsoft.com/VisualStudio/feedback/details/544358/more-efficient-htonl-ntohlLooks like microsoft need to do some serious soul searching.How long has the 486 been out for now?

author: the_raptor
author_rank: Regular Contributor
timestamp: December 09, 2010, 08:29:20 am
content: Quote from: RayJones on December 09, 2010, 06:47:16 amBut then you get screwed when you release the compiled code with optimisations on and get new fun strange bugs which you can't find in the unoptimised ASM

author: RayJones
author_rank: Frequent Contributor
timestamp: December 09, 2010, 08:32:26 am
content: Who said I release the optimised code versionI'd rather the slower code than weird interesting bugs which you can't single step debug through!

author: Unknown
author_rank: Unknown
timestamp: December 09, 2010, 10:17:26 pm
content: I prefer to always enable optimizations, and debug with the dual assembly / source code view, at least for embedded work. For PC's, I rarely work in C anyway. If single stepping seems strange, I can usually figure out from the assembly what's going on. I know some avr-libc functions (eg. avr/delay.h) won't work without optimizations. At least until 8-bit micro's are dead, performance, code size and power (race to idle) is an issue. If shipping unoptimized code is not an option, the only other sane option is developing with optimizations IMO, unless you have a sophisticated QA team.