Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core: Add compile time byte swapping (C11 version) #5453

Closed
wants to merge 2 commits into from
Closed

core: Add compile time byte swapping (C11 version) #5453

wants to merge 2 commits into from

Conversation

Kijewski
Copy link
Contributor

Please see #4812 first.

Using C11 you can tell the the value of an expression is known at compile:

_Generic(
    ((1 ? (char*) 0 : (void*) (ptrdiff_t) ((EXPR) - (EXPR)))),
    char*: COMPILE_TIME,
    default: RUN_TIME
)

This PR uses this feature to optimize HTONL and friends. They'll use shift-and-or if the value is known at compile time, otherwise __builtin_bswap…().

Drawback: _Generic needs C11 and is only implemented since GCC 4.9.

Kijewski added 2 commits May 19, 2016 11:53
To convert the supplied argument HTONL and friends will use a simple
formula instead of a function call, iff the value of the argument is
known at compile time.

This enables the use in enum definitions such as:

```c
typedef enum {
    A                       = CT_HTONS(0x0001),
    AAAA                    = CT_HTONS(0x001C),
} dns_query_type;
```

Closes: #3812
@Kijewski Kijewski added Area: core Area: RIOT kernel. Handle PRs marked with this with care! Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Impact: major The PR changes a significant part of the code base. It should be reviewed carefully labels May 19, 2016
@Kijewski
Copy link
Contributor Author

Major tag because of -std=c11

@Kijewski Kijewski added this to the Release 2016.07 milestone May 19, 2016
@miri64
Copy link
Member

miri64 commented May 19, 2016

I don't get what this macro does... @DipSwitch's code on the other hand I understand. Also what is with clang support?

@Kijewski
Copy link
Contributor Author

Clang supports generic selections since somewhen in 2012. Source: some blog that comes up if you google "clang generic selection".

@Kijewski
Copy link
Contributor Author

Kijewski commented May 19, 2016

The macro "selects" either byteorder_swaplc(V) (shift-and-or) or byteorder_swapl(V) (compiler intrinsic), depending on whether V is known at compile time.

It uses the type deduction in:

1 ? (char*) 0 : (void*) (ptrdiff_t) ((EXPR) - (EXPR))

If the value of EXPR is known at compile time, then the value of the whole ternary-expression is known at compile time. So the compiler can tell that the value is a char*, because 1 evaluates to true. If EXPR is not know, then the compiler has to use the common type of char* and void*, i.e. void*. The generic selection either follows the char* or the default case, depending on the outcome. The other case is simply thrown away as if was #if 0'd (well, it has to use proper syntax).

@jnohlgard
Copy link
Member

jnohlgard commented May 19, 2016

The biggest issue is probably the msp430 platforms which are currently stuck at gcc 4.6 for most users. The other platforms will likely be at 4.9 or later anytime soon because of good upstream support for the ports.
To use the newer msp toolchain we also need to add newlib support to msp430 and do some changes to the startup code. I don't have any msp430 hardware but if anyone wants to do it you can adopt my PR #4766 which has much of the work done, just needs a rebase and some linking fixes after some code refactorings in master.

@Kijewski
Copy link
Contributor Author

Hm, I thought a HTONL function that just does the optimal thing automagically would be the easiest option, but msp430 support is essential of course.

@DipSwitch
Copy link
Member

Interesting :), I'll soon give it a try :)

@jnohlgard
Copy link
Member

Won't make it for release because of missing msp430 support

@jnohlgard jnohlgard modified the milestones: Release 2016.10, Release 2016.07 Jul 12, 2016
else
ifeq ($(shell $(CC) -std=c99 -E - 2>/dev/null >/dev/null </dev/null ; echo $$?),0)
CFLAGS += -std=c99
CFLAGS += -std=c11
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Errrrr... portability?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[mlenders@sarajevo RIOT]<3 msp430-gcc --version
msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compare GCC wiki

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please read the comments in this PR ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyhow, this first checks for c99 and if successful, sets c11.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry for the noise... But up until this is resolved I would prefer the portable version at #3812.

@miri64
Copy link
Member

miri64 commented May 23, 2017

Okay it seems we progressed with c11 anyway, but the byteorder functions changed a little bit (they are now lower-case). @DipSwitch do you want to keep the upper-case variant for constant initialization (would be like we do with most other data types too). And after all: needs rebase.

@aabadie aabadie modified the milestone: Release 2017.07 Jun 23, 2017
@smlng smlng removed this from the Release 2017.10 milestone Nov 16, 2017
@smlng smlng added this to the Release 2018.01 milestone Nov 16, 2017
@smlng
Copy link
Member

smlng commented Jan 12, 2018

needs rebase, but also discussion seems inconclusive, and was postponed several times now. Remove milestone, for time being.

@smlng smlng removed this from the Release 2018.01 milestone Jan 12, 2018
@tcschmidt
Copy link
Member

@miri64 do you see a chance to progress this? Or shall we close?

@miri64
Copy link
Member

miri64 commented May 29, 2018

No real progress for >1 year, so I would say close. If someone disagrees, please don't hesitate reopen.

@miri64 miri64 closed this May 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: core Area: RIOT kernel. Handle PRs marked with this with care! Impact: major The PR changes a significant part of the code base. It should be reviewed carefully Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants