h2inc+

[Biterider]

Hi all
I started work on the next version of the C header translator, which I called h2inc+ to denote the extended functionality.

My goals at the moment are:

• Dual bitness (or pure x64)
• Get rid of some dependencies
• Better configurability
• Configurable and persistent database of gattered information
• Much less manual fixes (hard)
• Better management of the preprocessor pass (very hard)

It is a lot of (hard) work, but it is worth it. 
In particular, MASM64 could benefit from a fresh set of include files.

If you want to get involved, you are more than welcome to.

Biterider

[jj2007]

Excellent

I suppose you are aware of Gcc's option -E, which allows to get rid of most of the conditional stuff. Is there an equivalent option of MSVC?

[TimoVJL]

Being a while 

Code Select Expand

/E preprocess to stdout                /EP preprocess to stdout, no #line
/P preprocess to file


[C3]

Hi all
I started work on the next version of the C header translator, which I called h2inc+ to denote the extended functionality.

My goals at the moment are:

• Dual bitness (or pure x64)
• Get rid of some dependencies
• Better configurability
• Configurable and persistent database of gattered information
• Much less manual fixes (hard)
• Better management of the preprocessor pass (very hard)

It is a lot of (hard) work, but it is worth it. 
In particular, MASM64 could benefit from a fresh set of include files.

If you want to get involved, you are more than welcome to.

Biterider

This is useful, nowdays if I need something what is missing, I just search Visual C++ headers to get the pieces to work.

[Biterider]

Hi
I have done most of the porting work, implemented some missing switches and cleaned up the code from previous versions.
Now I'm getting closer to the real core of the application.
One thing I need some help on is how to translate this structure to asm. AFAIR, the bits are arranged in reverse order...

From DDE.h

Code Select Expand

typedef struct {
#ifndef _MAC
        unsigned short bAppReturnCode:8,
                 reserved:6,
                 fBusy:1,
         fAck:1;
#else
        unsigned short usFlags;
#endif
} DDEACK;
Biterider

[Vortex]

Japheth's h2incx :

Code Select Expand

DDEACK struct
ifndef _MAC
DDEACK_R0 RECORD bAppReturnCode:8,reserved:6,fBusy:1,fAck:1
DDEACK_R0 <>
else
usFlags WORD ?
endif
DDEACK ends

[jj2007]

I've started implementing the RECORD directive, but given that I've got ENUM and I've never used/or seen it used in modern times.. should I bother supporting it?

[Biterider]

Hi
It seems more complicated than linear mapping, isn't it?
https://stackoverflow.com/questions/19376426/order-of-fields-when-using-a-bit-field-in-c

@JJ: In the latest version of UASM, the RECORD directive is implemented and works as expected (MASM compatible).

Biterider

[Biterider]

Hi
The next issue is that all names in the RECORD directive must be unique.
Taking as example

Code Select Expand

DDEACK_R0 RECORD bAppReturnCode:8,reserved:6,fBusy:1,fAck:1

Code Select Expand

DDEACK_R1 RECORD bAppReturnCode:2,reserved:1,fBusy:1,fAck:12

This will not work because bAppReturnCode, reserved, fBusy and fAck have already been defined. 
To solve this we need a naming convention that includes the usage (record and member name) and the bit field name. Then there are the anonymous members too 

Biterider

[jj2007]

@JJ: In the latest version of UASM, the RECORD directive is implemented and works as expected (MASM compatible).

Hearsay

Jokes apart: that was a long discussion about the right order in RECORDs. Does anybody use them, though? I can't find any in 48k lines of my library code. But of course, they do exist and must be handled correctly.

[Biterider]

Hi

@JJ

Jokes apart: that was a long discussion about the right order in RECORDs. Does anybody use them, though? I can't find any in 48k lines of my library code.

Thanks for the link!
The question is how we want to deal with it. What are the best options?
Japheth had a good approach, but it has some flaws. As you can see here https://masm32.com/board/index.php?topic=276.msg1500#msg1500, he uses an incremental index to make the names unique. The problem is that you never know what the index is, and it can change from one translation to the next.
Using a naming scheme like the one I mentioned leads to very long names, which I personally am not happy with.

Biterider

[jj2007]

Code Select Expand

DDEACK_R0 RECORD bAppReturnCodeR0:8,reservedR0:6,fBusyR0:1,fAckR0:1
DDEACK_R1 RECORD bAppReturnCodeR1:2,reservedR1:1,fBusyR1:1,fAckR1:12
You won't need that frequently, but appending first and last letters would work.
IMHO the assemblers should learn how to deal with it. They don't have problems with identical names in structures, right? I am ready to say bye bye to M$ ML.exe and ML64.exe, since UAsm and JWasm are so much better and faster...

[jimg]

I use it in terminal program thusly:

; set up dcb with reversed fbits (BITRECORD in masm32 windows.inc is incorrect)
zBITRECORD RECORD zDummy2:17,zAbortOnError:1,zRtsControl:2,zNull:1,zErrorChar:1,zInX:1,zOutX:1,zTXContinueOnXoff:1,zDsrSensitivity:1,zDtrControl:2,zOutxDsrFlow:1,zOutxCtsFlow:1,zParity:1,zBinary:1

DCBz STRUCT
  DCBlength     DWORD ?
  BaudRate      DWORD ?
  fbits         zBITRECORD <>
  wReserved     WORD ?
  XonLim        WORD ?
  XoffLim       WORD ?
  ByteSize      BYTE ?
  Parity        BYTE ?
  StopBits      BYTE ?
  XonChar       BYTE ?
  XoffChar      BYTE ?
  ErrorChar     BYTE ?
  EofChar       BYTE ?
  EvtChar       BYTE ?
  wReserved1    WORD ?
DCBz ENDS

[Biterider]

Hi jimg
Windows.inc defines the RECORD for the DBC structure as

Code Select Expand

BITRECORD RECORD fBinary:1,fParity:1,fOutxCtsFlow:1,fOutxDsrFlow:1,fDtrControl:2,fDsrSensitivity:1,fTXContinueOnXoff:1,fOutX:1,fInX:1,fErrorChar:1,fNull:1,fRtsControl:2,fAbortOnError:1,fDummy2:17
which corresponds to the definition sequence in C

Code Select Expand

typedef struct _DCB {
  DWORD DCBlength;
  DWORD BaudRate;
  DWORD fBinary : 1;
  DWORD fParity : 1;
  DWORD fOutxCtsFlow : 1;
  DWORD fOutxDsrFlow : 1;
  DWORD fDtrControl : 2;
  DWORD fDsrSensitivity : 1;
  DWORD fTXContinueOnXoff : 1;
  DWORD fOutX : 1;
  DWORD fInX : 1;
  DWORD fErrorChar : 1;
  DWORD fNull : 1;
  DWORD fRtsControl : 2;
  DWORD fAbortOnError : 1;
  DWORD fDummy2 : 17;
  WORD  wReserved;
  WORD  XonLim;
  WORD  XoffLim;
  BYTE  ByteSize;
  BYTE  Parity;
  BYTE  StopBits;
  char  XonChar;
  char  XoffChar;
  char  ErrorChar;
  char  EofChar;
  char  EvtChar;
  WORD  wReserved1;
} DCB, *LPDCB;

Can you confirm that your reversed RECORD really works?

Code Select Expand

zBITRECORD RECORD zDummy2:17,zAbortOnError:1,zRtsControl:2,zNull:1,zErrorChar:1,zInX:1,zOutX:1,zTXContinueOnXoff:1,zDsrSensitivity:1,zDtrControl:2,zOutxDsrFlow:1,zOutxCtsFlow:1,zParity:1,zBinary:1

Biterider

[jimg]

I haven't looked at that code in five years, but it was working at the time.  There was a short discussion somewhere on this board, or the old one, can't remember which.  I'll try the program and look for the posts.