2 Dec
2007
2 Dec
'07
3:39 p.m.
On Sun, 2007-12-02 at 18:35 +0000, Krzysztof Foltman wrote:
Well, giving size and type 32 bits would give the data 64-bit alignment,
but that's a 16 byte event header...
64 bit will become the norm, sure, but does 64-bit alignment matter here
anyway? (I have no idea). We're probably not going to be firing around
arrays of floats to do vectorizable things with here
Not really, just casting a char* pointer to a struct to make life easy.
Dave Robillard wrote:
Well, we don't need that much space for type, and more for size would be
nice. The only practical limitation for size is probably something like
UDP packet size though, which fits within uint16_t easily.
We are definitely going to need some kind of shared data structure
extension, so really massive message are probably stupid. 16/16 works
and is un-weird.
More or less agreed. The size thing isn't
really an issue in practise,
just reaching for equivalence with OSC/Jack for equivalence's sake.
Dealing with a 24 bit number is pretty weird though. Worth it?
I prefer 16+16 to 24+8. I can see more uses for 16-bit types than for
24-bit sizes (basically, defining a new URI for every parameter exposed
by a plugin, you'll find people insane enough to try that). Perhaps you
can probably see the applications where 24+8 is more desirable. Decide
for yourself. The
'free' payload is tempting since the majority of events (at least
for now) are going to be 4 bytes of MIDI. OTOH, we probably want the
data itself aligned (consider e.g. ramp events)
We have 32-bit alignment for the data. Is 64-bit alignment worth
shooting for?
Yes, I think so. 64-bit platforms are getting more and more popular. BTW, does reading a double from address misaligned by
a dword involve
performance penalty? If not, we can say that we use alignment of
sizeof(void *) on a particular platform. Should be enough.
Life is easier and less problematic if we just pick absolute sizes and
stick with them (so the buffer has a precisely defined format anywhere).
I doubt this is a compelling enough reason to do otherwise.
These structs
don't actually 'exist', for the nth time ;) so the
compiler doesn't take care of any padding/alignment etc. We're defining
Well, at some point we're going to end up with some structs anyway :)
In other words, we can define the buffer content in
two ways:
1. By specifying offsets of particular fields (including payload fields
for every event type) as numbers.
[snip]
2. By defining it as C structures, and calculating
offsets based on
[snip]
We are very precisely defining the layout of a byte array, period. Yes,
we are discussing it in terms of structs for obvious reasons. The
constant resurfacing of this idea that they are different is getting
old... this is exactly the same as the current MIDI stuff but we're
adding a few things.
What we have right now is this:
/* 0 4 8 12 16
* | | |
* | | | | |
* | | | | | | | | | | | | | | | | |
* |FRAMES |SUBFRMS|TYP|LEN|DATA..
*/
On the plus side, 4 byte MIDI messages fit nicely in that 16 byte box,
entire message is 2 64-bit words, 64-bit aligned, no wasted space.
Extremely powerful timestamp, 65535 message types in one system at a
time, maximum message size 64K. Not too shabby... (though you can see
why I'm tempted to take a byte from type and give it to size).
The data itself isn't 64-bit aligned, but I'd have to see some real
reasons to care.
Whether the alignment of messages themselves in the buffer (via the
padding applied to data) is machine specific is a question (though not a
particularly significant one, IMO), but the layout of the message header
shouldn't be.
-DR-