lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] PPP LCP Phases Not Enum in 2.0.0 Beta


From: Greg Smith
Subject: Re: [lwip-devel] PPP LCP Phases Not Enum in 2.0.0 Beta
Date: Tue, 2 Aug 2016 17:44:52 +0000

Hi, Sylvain.

> From: Sylvain Rochet
> Sent: Monday, 01 August 2016 18:57
>
> On Tue, Aug 02, 2016 at 12:40:47AM +0200, Sylvain Rochet wrote:
> > On Tue, Aug 02, 2016 at 12:22:11AM +0200, Sylvain Rochet wrote:
> > > On Mon, Aug 01, 2016 at 09:50:30PM +0000, Greg Smith wrote:
> > > > Hello.
> > > >
> > > > In Lwip 1.4.1, the PPP LCP states (phases) were all defined as an
> > > > enum (typedef LinkPhase). This made seeing the state in a
> > > > debugger really nice -- it would show "PHASE_DEAD", for example.
> > > > In 2.0.0 Beta1, they have been converted to #define macros. Now
> > > > the debugger only shows a number (0, for example), which isn't as
> convenient.
> > > >
> > > > So:
> > > >
> > > > 1) I'd like to understand why this change was made.
> > >
> > > In C, an enum type is always an int, which is a 4-byte value on
> > > 32-bit systems (also 4-byte on LP64, LLP64, and 8-byte on ILP64, but
> > > we are a bit outside lwIP targets here). So this is to save 3 (or 7)
> > > bytes of RAM per state value, and it matters.

I don't see how enum uses any extra RAM compared to literals. #define macros, similar to enum, are also a minimum of type int. (Well, technically, the numeric constant (literal) that the preprocessor replaces in the text is at least of type/size int. C99:6.4.4.1)

Since C, unlike C++, doesn't treat enums as purely their own type (they're just int after all), they can easily be stuffed into any primitive type of sufficient size -- just as any numeric literal (#define) can.

For example, fsm.state can still be a u8_t type (i.e. no need to explicitly change it to type enum); the compiler will implicitly do the casting for you (so you don't even have to explicitly cast) and the value stored in RAM for the state is only a single byte. (Well, assuming the compiler doesn't pad the struct up to a 2- or 4- byte boundary, which it probably does. If it does, then the whole RAM argument is invalid anyway because it is taking up extra bytes for padding).

But to prove it to myself I changed the PPP_FSM_* to an enum type and recompiled my whole project (using gcc). I compared the emitted assembly for just one function (I'm lazy), fsm_lowerup(), and it was identical opcodes to the #define version.
Additionally, the compiler/linker-reported text, data, and bss sizes were also identical between the two.

-- G



This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]