[Freeciv-Dev] Re: Generator script

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Sep 02, 2002 at 05:23:32PM +0200, Peter Hans van den Muijzenberg wrote:
> Hi,
> 
> On 28-aug-02 Raimar Falke wrote:
> RF> On Wed, Aug 28, 2002 at 07:27:00PM +0200, Peter Hans van den Muijzenberg
> RF> wrote:
> 
> Hm, I seem to have addressed a mailing list. Somehow, I didn't notice that
> in the docs. Just refer me to anyone specific if/when I should get off the
> list.
> 
> 
> PHM>> I'm really here to see if the networking code can be split off from
> PHM>> the game code, so it can be reused for other net games. But now that
> PHM>> I'm here:
> 
> PHM>> Is there still a need for a script that generates packet send and
> PHM>> receive functions? there are some issues, but in itself this seems
> PHM>> doable.
> RF> I'm also toying with this idea.
> 
> That's probably because it is mentioned in the hackers document. (-:
> 
> RF> It is possible but there is currently no strong need for this.

> OK, so apparently there's no such script at the moment. I've started putting
> some lost moments into a perl script, since even if it's of little use now,
> it would be preferable to already have the script if does becomes of use
> later. Also, if the networking code is indeed used for a different game,
> the game packets for that game will need routines as well.
> 
> So far, I did the file parsing. It operates the simple way: You add a marker
> (atm the comment 'GENERATE') before any structure you want to be sendable,
> and the script gets the structure out. Only other difference in my test
> file, packets.h, is that I split off nameless, embedded structures. I'd
> rather not go there in a simple script. Would this be a problem? (I don't
> know the design decision that created them to begin with.)
> I believe I could see one more problem coming, but I'm not sure now:

IMHO: before we create such a script we should "normalize" (an
overloaded term these days) the packets. There are irregularities
like:

  if(unit_type_flag(packet->id, F_PARATROOPERS)) {
    cptr=put_uint16(cptr, packet->paratroopers_range);
    cptr=put_uint8(cptr, packet->paratroopers_mr_req);
    cptr=put_uint8(cptr, packet->paratroopers_mr_sub);
  }

or the handling of the helptexts. You also have to tag the ints in the
struct packet_* so that the script knows if it needs to send a 1, 2 or
4 byte value.

>  Is there one function that handles a packet named differently?

I don't understand.

> I'm adding the actual generation (I just added generating the
> send-functions, but they don't have any content yet. (-:), but in checking
> with packets.c I came about something curious:
> 
> Every send_packet-function, apart from converting, appears to do the same
> three things:

> - Create a dynamic buffer;

It doesn't use malloc but allocates it on the stack which is very cheap.

> - Write the well-formed packet-length into it;
> - Pass the packet-length and the buffer to the send_packet_data routine.
> 
> Is there a specific reason for not having:
> 

> - One static buffer for all (outgoing?) packets;

It is possible that a send_packet_* function calls another one. AFAIK
there is no such case at the moment. send_attribute_block comes
closest to this.

It is cleaner this way. Don't use globals.

> - The send-packet function merely /passing/ /in/ the packet-length in
> send_packet_data;

> - The send_packet_data routine adding the well-formed packet-length to the
> packet?

Yes this is quite possible. And with the recent invention of
SEND_PACKET_* it should be a small patch.

> (I could imagine an implementation where these buffers were held in a
> send-queue, but currently there's no benefit, AFAICS.)
> 
> 
> PHM>> BTW, do you know that the current implementation of packets.c is not,
> PHM>> as the documentation has it "highly portable" C-code. You'd never
> PHM>> notice as freeciv already requires IX-like for other issues, but the
> PHM>> conversion calls are GNU-specific, or possibly IX-specific.
> RF> IX-specific?
> 
> 
> In case you're asking about the term:
> 
> UNIX- and/or ONIX- and/or AMIX- and/or POSIX- and/or AIX- and/or ...
> specific, since each machine had it's own implementation. 
> Depending on the system you're working with, this could be generalized to
> *IX-specific, #?-specific, .*IX-specific, and probably a dozen others
> abbrevations, or to abbrevate the abbrevations: IX-specific.

Ahhh I see.

> In case you're asking about the details of the specific-ness:
> 
> Some of the routines for system-independent passing of arguments implement
> this by the use of endian-independent conversion routines.
> 
> Eg. packets:: put_uint16(unsigned char *buffer, int val)  uses 
> machine/endian.h:: unsigned short htons( unsigned short). 
> 
> These, TTBOMK, are not part of the C-standard (1988), but rather, I expect,

> have been created as part of the mechanism of GGC to create

GCC?

> machine-independent code.  However, they could instead originate from some
> IX-release. If I were to move this C-code to, I don't know, one-on-one game
> computers, their compilers might not include these functions, which is a
> limit to the code's portability.

According to my man-page htonl, htons, ntohl, ntohs are from BSD 4.3.

It looks to me that this is rather a libc than a compiler issue.

Nevertheless reimplementing these functions is easy. But IMHO we can
expect to find them under this name of similar on every system because
they are needed for TCP/IP.

> Similarly, I'm not sure FreeCiv can guarantee that an int will
> actually hold 32 bit (or more).

Freeciv runs on platforms where int is 64bit. But it will break on
sizeof(int)<4 and also if sizeof(int)!=sizeof(enum). And maybe some
others.

> For both issues it may be easier to adapt the documentation than the code,
> but once you describe code as "highly portable", you probably should
> mention any limitations to that portability.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  The trick is to keep breathing.