Category Archives: neptune

Argh, this whole “neptune looks like C#” thing is self-perpetuating. After we first noticed the similarities between the languages I looked into C# a bit more, and having that at the back of my head as we’re discussing the language only paves the way for new C#-like constructs and so the hideous circle continues.

Example. And this is where smalltalk programmers should look away or at least read the disclaimer before continuing. The example is about synchronization and locking. In java, all objects can be used as monitors and you usually guard a critical section by synchronizing on some object:

final Object lock = ...;
synchronized (lock) {
  // critical section
}

That’s pretty readable even though it’s somewhat warped that all objects can be used as monitors. But that’s beside the point. In smalltalk it’s even neater since you can use blocks and so don’t need a special synchronized statement, you can just call a method on a Monitor or Mutex:

mutex acquireDuring: [
  // critical section
].

In neptune, being derived from smalltalk, we also have blocks (they’re called functions) and until recently we used the exact same technique as smalltalk for synchronization:

Mutex mutex = ...;
mutex.acquire_during(fun {
  // critical section
});

Yeah I know, it doesn’t look very good. It’s exactly the same as in smalltalk except that method calls are written as mutex.acquire_during(...) and that the block syntax has changed into fun { ... }.

It turns out that you use acquire_during all over the place so we really want a more concise syntax. The idea is to add a special purpose syntax for acquiring a resource, for instance a mutex or a file, in a particular scope that makes sure the resource is released properly. It’s an old idea we’ve had floating around but it never really got anywhere because we couldn’t find the right syntax.

This afternoon we ended up discussing this problem again and it seems like we finally have a strawman: the using statement:

Mutex mutex = ...;
using (mutex) {
  // critical section
}

C# programmers will find this very familiar — C# has a construct with a very similar purpose and a very similar syntax. It is important, though, to point out that we haven’t taken the whole construct from C#, only the name of the keyword. But that’s a pretty important part of the construct.

As with all out shorthands, the using statement is just syntactic sugar for a simpler construct, in this case a method call:

mutex.using(fun {
  // critical section
});

Any object is free to implement the using operator so it’s a much more general construct than synchronized in Java. A using statement can also define variables, for instance when acquiring a resource produces a result:

File my_file = ...;
using (InputStream stream : my_file) {
  // read file
}

Will this be a popular statement? I think that probably depends on how we use it in the libraries. But that goes for most of the language constructs, if we don’t use them in the libraries they probably won’t be used by others either. We’ll see.

Disclaimer: I cannot be held responsible for any discomfort felt by smalltalkers while reading this post. To a smalltalk programmer the following probably seems like utter insanity since smalltalk already has a great solution to the problem in this example, and the people who are designing this language are all smalltalk programmers. I’m trying to find the courage to write a post about why we’re moving away from smalltalk and I’m not quite there yet.

Ted Neward compares a handful of different languages (Java, C#, VB, Scala and Ruby) with respect to how much code it takes to express a simple person concept:

A Person has a first name, a last name, and a spouse. Persons always have a first and last name, but may not have a spouse. Persons know how to say hi, by introducing themselves and their spouse.

Of course, I couldn’t help but compare it with neptune which (sigh of relief) compares favorably:

class Person {

  readable String first_name, last_name;
  readable Person spouse;

  Person(String -> first_name, String -> last_name,
    Person -> spouse = null);

  String to_string() {
    if (spouse==null) return "Hi, my name is ${first_name} ${last_name}";
    else return "Hi, my name is ${first_name} ${last_name}"
      ", and this is my spouse ${spouse.first_name} ${spouse.last_name}";
  }

}

Personally, I think that is more readable than both scala and ruby but of course I’m biased. Here’s a short run through of what’s going on in this code.

The modifier readable means that the field is given a read accessor. So instead of writing

readable String first_name;

you would get the exact same result if you wrote

String first_name;

String accessor first_name {
  return first_name;
}

In the Person class above, unlike C, C++ and Java, spouse.first_name does not just read the field first_name in spouse directly but calls the read accessor called first_name. In neptune, hidden or no modifier defines a field but doesn’t create accessors, readable gives it a read accessor, writable gives it a write accessor and visible gives it both ¹.

The Person “method” is the constructor. The arrow notation means “assign this argument directly into the specified field” and the = null specifies a default value for a parameter (as in C++). The constructor above could be written alternatively as the following, which is completely equivalent but, I think, a lot less clear:

Person(String _first_name, String _last_name, Person _spouse) {
  first_name = _first_name;
  last_name = _last_name;
  spouse = _spouse;
}

Person(String _first_name, String _last_name) {
  this(_first_name, _last_name, null);
}

If you want to go completely nuts you can even expand the constructors into two static new operators and an instance initializer. And once you’ve done that it’s pretty easy to see that basic neptune is almost just smalltalk with a warped syntax. But I digress…

By the way, if you’re not into the whole type thing you’re free to leave out the types

class Person {

  readable var first_name, last_name, spouse;

  Person(-> first_name, -> last_name, -> spouse = null);

  to_string() {
    if (spouse==null) return "Hi, my name is ${first_name} ${last_name}";
    else return "Hi, my name is ${first_name} ${last_name}"
      ", and this is my spouse ${spouse.first_name} ${spouse.last_name};
  }

}

[1]: Why didn’t we use public and private instead of visible and hidden? Well, our modifiers mean something different from Java or C++’s do in almost all positions where they occur. We thought that it was important to avoid misleading people by emphasizing the similarities, which I think we would have if we had used public and private, and instead emphasize the differences by choosing completely different keywords.

Pretty early on in the development of the neptune language we noticed that if you want syntax coloring when editing neptune source in editors that didn’t know about the language, a syntax coloring mode for C# is usually the closest approximation. That may not be a coincidence: I don’t actually know C# very well, I don’t think anyone in our group do, but for some reason neptune has drifted in C#’s direction.

Amazingly, the C# also seems to be drifting towards neptune: the new C# 3.0 spec describes the new constructs in C# 3.0 and a few of them are very similar to constructs in neptune.

One new construct in C# 3.0 is implicitly typed local variables. For instance, you can write

var i = 5;
var s = "Hello";

and the compiler will infer the variable types for you from the initializer and understand the code above as if you had written

int i = 5;
string s = "Hello";

In neptune you can also declare variables without specifying the type, using the exact same syntax:

var i = 5;
var s = "Hello";

In neptune, however, the type is not inferred but left undefined — neptune has optional typing and you are always free to leave out the types. So where this is illegal in C#:

var x = 5;
x = "Hello";

since x is inferred to be an integer, it is perfectly legal in neptune. You are also free to leave out the initializer in neptune, since we don’t need it to infer the type as they do in C#. So the constructs are a little different when you look closely but still pretty similar.

Another new construct in C# 3.0 is collection initializers. You can now write

new List<int> { 1, 2, 3, 4, 5 }

which gives creates a new list containing the five specified numbers. In neptune you can do exactly the same (except that we don’t have generic types) and, again, with exactly the same syntax:

new Vector { 1, 2, 3, 4, 5 }

Not only do the two constructs have the same syntax, the coding convention used in the spec is the exact same as I use in my code: a space after the class name, before the first element and after the last.

There is a subtle difference in what the code means in C# and neptune, but it makes almost no difference in how the constructs works, only how efficiently it can be implemented. In C# the expression above is implemented by adding the elements to the list:

List<int> list = new List();
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

In neptune collections have a special collection constructor and the elements are given to the collection constructor in a special “primitive” collection:

var raw_elements = #{1, 2, 3, 4, 5} // "magic" primitive collection
Vector.new{}(raw_elements)

Our model has the advantage that we can optimize the allocation of the primitive collections which can often be pre-allocated and, if necessary, placed in ROM on small devices. It also means that collections are given all the elements at once and are hence free to implement new{} in smart ways. In C#, new List<int> { 1, 2, ..., 1000 } must be implemented using 1000 .Adds, whereas new Vector { 1, 2, ..., 1000 } in neptune can be implemented extremely efficiently no matter how many elements are added. (How? By using the primitive collection as a backing store and using copy-on-write if the vector is modified. And you can be much smarter than that if performance is an issue).

Unlike C#, this syntax can also be used to initialize mappings in neptune:

new TreeMap { 1 -> "one", 2 -> "two" }

On the other hand, C# allows this syntax to be used to initialize arbitrary objects:

new Point { X = 12, Y = 16 }

Considering that we knew nothing of these constructs in C# and the C# people of course didn’t know what we were doing (the spec came out before we even started working on neptune) it’s interesting how alike they are. I’m optimistic take it as a sign that maybe we’ve hit a design that will feel natural for people used to C-like languages.

For the technically minded, Ted Neward writes about the gory details of the new C# features. For an overview of all the new features a good place to look is the Code Post.

In the new neptune language, we’ve experimented with various shorthands that allows you to write code that is more concise and readable than equivalent code in neptune’s “parent” languages C/C++ and smalltalk. Most of the new constructs are identical or similar to well-known constructs in existing languages but usually have a different twist. The most “twisted” of our new constructs is constructors.

One of the things that’s bothered me most in smalltalk is all the boilerplate code you need when writing a new kind of object: to construct an object you usually need two methods, a static constructor method which is mostly boilerplate code and an init method for initializing the instance. Using this pattern, the construction part of a Point would look something like this:

Point = Object (

  | x y |

  initPointX: xInt y: yInt = (
    x := xInt.
    y := yInt.
  )

) class (

  newX: xInt y: yInt = (
    | result |
    result = super new.
    result initPointX: xInt y: yInt.
    ^ result.
  )

)

With this implementation you create a new point by writing Point newX: 0 y: 1. Here’s the same code again with all the code that’s not boilerplate underlined:

Point = Object (

  | x y |

  initPointX: xInt y: yInt = (
    x := xInt.
    y := yInt.
  )

) class (

  newX: xInt y: yInt = (
    | result |
    result = super new.
    result initPointX: xInt y: yInt.
    ^ result.
  )

)

The only “interesting” code in the common case is 1) how many arguments does the constructor expect, 2) how is the super constructor invoked, and 3) how is the instance initialized. And once you’ve written a few dozen objects you start to get real tired of initWhatever methods.

One of the shorthands we’ve added in the neptune language is constructors. In neptune, you could write the class above as:

class Point {

  hidden int x, y;

  Point(int _x, int _y) {
    x = _x;
    y = _y;
  }

}

To create a new point, you write new Point(0, 0). In this code, all you see is the non-boilerplate code from the example above. And in fact you don’t even see the call to the super constructor because it is generated for you if you don’t write it yourself. Constructors can be used in much the same way as constructors in C++, Java or C# but are also very different from constructors in those languages. First of all, there are no special rules about how you implement your constructors beyond the rule that if you don’t write a call to super(...) somewhere one will be generated for you. But you’re free to call the super constructor whenever you want and as many times as you want.

Another difference from traditional constructors is that neptune constructors are only a shorthand that you don’t actually need to use to construct objects. When you write new Point(0, 0), that simply means calling the new method on class Point, which you are free to implement any way you want. An equivalent implement of a Point constructor would be

class Point {

  hidden int x, y;

  void initPoint(int _x, int _y) {
    x = _x;
    y = _y;
  }

  static operator new(int x, int y) {
    Point result = new super();
    result.initPoint(x, y);
    return result;
  }

}

All that happens when you use the constructor syntax is that the two methods are created for you: an instance initializer containing the body of the constructor and a static new operator the creates the object and calls the initializer. One of the problems with constructors in many languages is that calling the constructor in a class must return an instance of that class. In smalltalk, “constructor” methods are free to return whatever they want which can be a very powerful tool. And the same thing is true in neptune since you are free to implement the new operator however you want. But most of the time constructors simply create and initialize instances, and in those cases you can use the shorthand.

There is one piece of boilerplate left in the code above, however. When I write a constructor, the arguments are very often stored in fields in the object. In the point example above, that’s all the constructor does: stores _x and _y in x and y. Because this happens so often, we’ve added another shorthand for storing arguments in instance variables:

class Point {

  hidden int x, y;

  Point(int -> x, int -> y);

}

The arrow notation, int -> x means that the constructor takes an integer argument and stores it in the field x. In this case we don’t even need to give the constructor a body since all it does is set the variables. Compared with the original smalltalk code, and the fully expanded neptune code, the last example is not only much faster to write but easier to understand and maintain. And there’s no “magic”: every shorthand used above maps in a trivial way to other constructs in the language.

The last constructor-related shorthand we’ve added is instance variable initialization. In many cases, instance variables must be initialized before the object can be used. For instance, a PushButton might have a list of button click listeners:

class PushButton {

  hidden List button_click_listeners;

  PushButton() {
    button_click_listeners = new LinkedList();
  }

}

The disadvantage of this is that all constructors need to initialize the list of listeners (or call a constructor that does) and that it is less clear how the field is initialized since you need to inspect all constructors to see that. An alternative way to write this is to initialize the field directly:

class PushButton {

  hidden List button_click_listeners = new LinkedList();

}

This means that same as the code above but is more compact and, again, easier to understand and maintain.

We have a bunch of other shorthands which I’ll probably write more about later, including collection initializers, local functions, and (possibly) default arguments.

Today, it seems like we resolved the issue that has so far been the most controversial in the design of the new neptune language: how to build strings. I wouldn’t have expected that something like that should be controversial, but it turns out that there are a lot of different ways to do this.

One of the nice things we had in smalltalk that we’ve lost in the new language is cascaded sends. In smalltalk, you can use cascaded sends (using ;) as a shorthand when sending multiple messages to the same object. This is really convenient, for instance when creating a new array:

^ (Array new) add: 1; add: 2; add: 3.

Here, I create a new array, send three messages to it which add the elements, and then return it (^ is return). To get the same effect in Java, you’d have to do something like

List a = new ArrayList();
a.add(1);
a.add(2);
a.add(3);
return a;

which is a lot less concise.

The place where I’ve used cascaded sends most is for printing. If I want to print the value of the variables x and y, I’ll write

System out show: 'x = '; show: x; show: ', y = '; show: y; nl.

Here, I’m sending four show: messages to standard out and then sending a newline. In java, the code would look something like this:

PrintStream out = System.out;
out.print("x = ");
out.print(x);
out.print(", y =");
out.print(y);
out.println();

Of course, in Java you’d never do that; instead you’d create a single string and just do one print:

System.out.println("x = " + x + ", y = " + y);

A different situation is when objects are asked to return a string representation of themselves. In Java, you’d do pretty much the same thing as when printing: construct a single string and then return it instead of printing it:

public String toString() {
  return "a Point ( x = " + this.x + ", y = " + this.y + " )";
}

In our smalltalk system, there was no toString method on objects — instead, there was a printOn: method so instead of returning a string you would print the object on a stream using cascaded sends again:

printOn: aStream
  aStream show: 'a Point ( x = '; show: x; show: ', y = '; show: y; show: ' )'.

It was decided pretty early on that in the new language we’d go for a model similar to Java’s (and most other languages’) rather than the printing approach used in smalltalk.

The printing approach has the advantage that it can be more efficient, since no strings are actually constructed, but on the other hand you rarely have time-critical applications that do a lot of object-printing. And our expectation is that a toString-like mechanism will be easier for programmers to work with. Finally, having a printOn: method on Object would mean that we would have to have some form of streaming support in the core library, and we’re trying to have as little code as possible in the core.

Having decided this, the question arises: what mechanism will we use to construct strings. In most languages I’ve worked with you can concatenate strings using an infix operator, often +. This works nicely if you’re concatenating strings, but often you’re creating strings from objects that aren’t strings themselves — in the point example above, x and y could be any kind of objects. So either you have to manually convert the objects that aren’t string into strings, like this…

public String toString() {
  return "a Point ( x = " + this.x.toString() + ", y = " + this.y.toString() + " )";
}

…or define the string + operation so that it automatically converts its arguments into strings. Both solutions sort of suck and none of them solve the problem that concatenating strings is expensive. The java spec says that the compiler is free to optimize string concatenation using StringBuffers, but that relies on static type information (which we don’t have) and is just not a clean solution since it doesn’t work in all cases.

One of the very first methods I wrote in the new system was the infix ++ operator on objects. a ++ b returns an object whose string representation is a‘s followed by b‘s. That way, the as_string method (which is neptune for toString) could be written as

String as_string() {
  return ("a Point ( x = " ++ x ++ ", y = " ++ y ++ " )").as_string();
}

The result of ++ works sort of like a StringBuffer int that it is not a string but is used to construct strings. The advantage over the java model is that we don’t need any special rules about how string concatenation works, and that the as_string method on the result of a ++ can be implemented so that constructing the result is as efficient as using a StringBuffer in Java.

We used that for a bit but later we decided that we wanted to use ++ for incrementing variables like in C. And that’s where all the trouble began. The first thing we tried was to keep the operation but just use a different operator. A lot of different operators were suggested (I liked +: or &:) but noone really liked any of them. We discussed it a few times over the last month or so but nothing came of it.

After using it for a while, another problem with ++ turned out to be that it is a bug generator: using "foo" ++ "bar" as a string will cause an error, the same way that it is illegal to use a StringBuffer in place of a string in Java; you have to use ("foo" ++ "bar").as_string(). But Java has the advantage of a type system so you’ll see the problem at compile time, whereas we don’t see the problem until runtime. So we discussed various completely different approaches — varargs, using the same model as Java, etc. When the dust settled there hadn’t been any ideas that everyone (or anyone for that matter) really liked.

But when people came in this morning, two of us had the same idea: to use string interpolation. String interpolation allows you to write general expressions within string constants, that are evaluated and “spliced” into the string:

String as_string() {
  return "a Point ( x = ${x}, y = ${y} )";
}

In the above expression, when the string is evaluated, anything between ${ and } is evaluated and spliced into the string, so ${x} is replaced with the value of x and ${y} is replaced with the value of y. Perl, ruby and python all have some form of this, and my attitude has been that it was a neat but sort of cheesy construct that didn’t belong in a “serious” language. But no one had strong feelings against, except that we couldn’t agree in the exact syntax:

  "a Point ( x = ${x}, y = ${y} )"
  "a Point ( x = {x}, y = {y} )"
  "a Point ( x = %{x}, y = %{y} )"
  "a Point ( x = $x, y = $y )"
  "a Point ( x = `x`, y = `y` )"
  `a Point ( x = ${x}, y = ${y} )`

…etc. etc. Currently it seems like we’re going with ${...}, which is my favorite. And then we’ll reserve $ so if you want a dollar sign in a string you’ll have to write \$, which allows us to later introduce shorthands like $x (or $x.foo or $x[0] or…). Even if I think it’s kind of cheesy I think it will be a hit, especially with C programmes who are used to printf-style string formatting.

Last night I started working an a program for making the interface between Neptune and C code easier to work with. Here, I’ll explain what makes the interface difficult in some cases and how this new tool will make it easier. Beware: long post!

The OSVM system has a really simple interface for calling external C code. You can define a Neptune method as external by using the extern keyword:

class X {
  extern int my_external_method(int a, int b);
}

When you invoke that method, the C function named my_external_method in the underlying system is located and called. Similarly, if I want to call the standard time function in C I just make an external method called time in some Neptune object and when I invoke that method, the call will go though to the time functino in C because they have the same name. You can only pass integers as arguments, and only integers can be returned from the function. Nice and simple.

Well, except that sometimes you really want to call a C function with a piece of structured data, or have it returned. For instance, you might want to use a graphics library written in C, and in that case it would be nice to be able to pass in a text string when calling the draw_string function:

void draw_string(char *str, int x, int y);

How do you get from a fancy Neptune string with bells and whistles to a character array, and how do you pass it to the function? The solution is to use Memory objects. A Memory object allows you to allocate and deallocate memory in the underlying system. It is essentially the same as malloc and free except that a memory object checks that you don’t access memory outside of the allocated area. So you can create a character array by allocating a piece of memory of the right size, copying the characters from the Neptune string into the memory area, and then finally pass the address of the memory to the external call:

String str = "Whatever...";
Memory mem = new Memory(str.size + 1); // Allocate memory
for (int i = 0; i < str.size; i++)
  mem.set_byte(i, str[i].as_integer()); // Copy characters
mem.set_byte(str.size, 0); // Null-terminate
draw_string(mem.address, 0, 0); // Perform call
mem.free(); // Free memory

We’re still just passing integers through the C call, but one of them is a pointer to the character array which contains our string. Unfortunately, since the memory is allocated in the underlying system it is outside the reach of the garbage collector so you have to do manual memory management. However in some cases, for instance with externalizing strings, there are convenience methods that free you from dealing directly with memory objects:

str.externalize_during(fun (Memory c_string) {
  draw_string(c_string.address, 0, 0);
});

In this case, string has a method which externalizes the string, invokes the given block, and then cleans up.

A character array is a pretty simple thing and the approach above solves some but not all problems with external calls. For instance, say you want to use an external C library that can use GPS to give the current position:

struct point {
  int x, y;
}

struct point *get_position();

When you call this external function from Neptune you will get the address of a C point structure. Now, you can access the contents of this piece of memory by using a memory object. Memory objects can be used in two ways: either to allocate a fresh piece of memory or to give access to a piece of memory that has already been allocated:

int address = get_position();
Memory mem = new Memory(address, 8); // using existing memory
int x = mem.get_int(0);
int y = mem.get_int(4);

Here we have to make some assumptions about how structs are implemented in C. We guess that the point takes up 8 bytes of memory and that x and y are integers starting at byte offset 0 and 4 respectively. It is probably true, but it really is just a guess. The C standard does say something about the implementation of structs, but it doesn’t define them completely. For instance, it says that x must occur before y. However, there are holes in the standard which allows different compilers to implement structs differently. Some standard structures, for instance in network code (tcp.h), use a lot of bit fields which allows you to access individual bits or groups of bits within a struct. The C standard says that a C compiler is free to decide how to implement bit fields. So if an external call returns a TCP header I may have access to the contents of the struct, but if I want to know the value of the SYN field I have no way to know where to find it. Bugger.

Maybe I’ll experiment with my compiler and figure out that it always puts SYN in word 4 as bit 21. That’s not enjoyable work, and a TCP header has more than 15 fields so that produces a lot of nasty code full of magic numbers.
Worse, the code is now tied to a particular compiler, in fact a particular version of a particular compiler since they are free to change the implementation of structs in a later version. Bleh!

As I said in the beginning, I’ve started working on a tool for making interaction easier between Neptune and C code. In fact, the tool is exactly designed to, if not solve the problem with structs, then at least make it a lot easier to deal with. The tool processes the definition of a struct and then generates a Neptune class which wraps a memory object and provides accessors for the struct’s fields. For instance, for a simple example such as the point struct from before:

class Point {

  Memory memory;

  Point(int address) {
    memory = new Memory(address, 8);
  }

  int accessor x {
    return memory.get_int(0);
  }

  int accessor x=(int new_x) {
    memory.set_int(0, new_x);
  }

  ...

}

So now you can access a point struct as it if was a real object

Point p = new Point(get_position());
int x = p.x;
p.y = 8;

without dealing with offsets and other nastiness. Of course, that doesn’t actually solve the bitfield problem, I just wanted to show how the interface worked.

The tool deals with the bitfield problem by simply asking the the compiler how the layout of a structure is. When generating the Neptune class for a structure, you must also specify which compiler you’re using. Through various trickery, the tool gets the compiler to describe the layout of the structure and uses that information to generate the class correctly. That way the tool takes care of determining, for instance, where the SYN bit is an a TCP header is, and ensures that the code for extracting and setting that bit is correct. If the compiler changes the way it lays out structures the generated code will break, but you can just run the tool again and get new working classes. It doesn’t solve all problems but it does in fact solve the problems that can be solved. And besides figuring out the layout of bit fields, it generates code that makes for really easy access to the fields, for instance setters so you can do

TCPHeader hdr = new TCPHeader();
hdc.SYN = true;
hdr.ACK = false;

The SYN=(bool v) accessor handles all the bit fiddling and masking which causes the bits to be set correctly in the underlying C structure. This means that it will behave correctly if you pass the structure to an external call (using hdr.address):

extern void process_header(int header);
...
process_header(hdr.address);

void process_header(struct tcphdr *hdr) {
  if (hdr->SYN) {
    ...
  }
}

How does the tool figure out what the layout of a structure is? It generates a C program that uses the struct, compiles it with the specified compiler, and then runs the program which prints out a description of the structures. It then uses that description when generating the Neptune classes. I can’t take credit for that idea, Kasper came up with that. For instance, if you want to know the offset of point.y you can use the offsetof macro which is defined in stddef.h. For each member, the generated C program contains a line like this one

printf("%s %s %i", "point", "y", offsetof(struct point, y));

Lo and behold, when I run the program it prints out

point y 4

One problem with this is that it doesn’t work with bit fields — I can’t do offsetof(struct tcphdr, SYN) because you can’t take the address of a bit field and that’s how offsetof is implemented. Instead, I use a little trick which I can take credit for: I simply fill the struct with zeroes, then set the field to the largest possible value it can contain, and then scan through the struct bit-by-bit to find the area where bits have been set.

struct tcphdr my_hdr;
memset(&my_hdr, 0, sizeof(my_hdr));
my_hdr.SYN = 1;
find_set_bits(&my_hdr);

Cheesy eh…

The tool is not really done but neither is the new OSVM containing Neptune. Both will be freely available later this spring…