h2incx

[jj2007]

I started the topic to see if anyone wanted to use Japheth's h2incx to try and construct a working readable set of includes for the Watcom forks, I wonder why it changed to a debate about structures.

MSDN Structure Alignment, Visual Studio 6.0 (my highlighting):

The default pack size for Windows 3.x is 2, whereas the default for Win32 is 8.

Hutch,

This is the trickiest single question with regard to the include files. I've checked Windows.inc (the 32-bit version) for structures containing QWORDs - there are about 17 only. And so far, luckily, there is no problem with ALIGN 4:

Code: [Select]

JIT_DEBUG_INFO STRUCT
   dwSize                 DWORD ?
   dwProcessorArchitecture DWORD ?
   dwThreadID             DWORD ?
   dwReserved0            DWORD ?
   lpExceptionAddress     QWORD ?
   lpExceptionRecord      QWORD ?
   lpContextRecord        QWORD ?
JIT_DEBUG_INFO ENDS
The dwReserved0 element provides the ALIGN 8 for lpExceptionAddress 8)

Did you sneak that in, or was it like that in the original M$ headers? Has anybody ever used this one?

Code: [Select]

SHQUERYRBINFO STRUCT
 cbSize         dd ?
 i64Size        qword ?
 i64NumItems    qword ?
 SHQUERYRBINFO ENDS

[sinsi]

Visual Studio 6
Porting 16-Bit Code to 32-Bit Windows
1998

jj, are you on a nostalgia trip?

[jj2007]

No, sinsi, but that was the only document where they clearly explained how structure alignment works.

[hutch--]

> jj, are you on a nostalgia trip?  :P

[sinsi]

https://msdn.microsoft.com/en-au/library/83ythb65.aspx?f=255&MSPPError=-2147217396

Without __declspec(align(#)), Visual C++ generally aligns data on natural boundaries based on the target processor and the size of the data, up to 4-byte boundaries on 32-bit processors, and 8-byte boundaries on 64-bit processors.

[hutch--]

Bingo  :t

[TWell]

h2incx have problem with DECLSPEC_ALIGN(16)

Code: [Select]

typedef struct DECLSPEC_ALIGN(16) _M128A {
    ULONGLONG Low;
    LONGLONG High;
} M128A, *PM128A;


Code: [Select]

typedef struct __declspec(align(16)) _M128A
{
ULONGLONG Low;
LONGLONG High;
} M128A, *PM128A;


[jj2007]

https://msdn.microsoft.com/en-au/library/83ythb65.aspx?f=255&MSPPError=-2147217396

Without __declspec(align(#)), Visual C++ generally aligns data on natural boundaries based on the target processor and the size of the data, up to 4-byte boundaries on 32-bit processors, and 8-byte boundaries on 64-bit processors.

Sinsi, that is a) either Chinese or Australian and b) microsoft.com/en-au, so it's not valid for the rest of the World 8)

(besides, I have a 64-bit processor - or did they mean 64-bit OS? it's Redmond speaking, so I have my doubts ::))

MSDN Structure Alignment, Visual Studio 6.0 (my highlighting):

The default pack size for Windows 3.x is 2, whereas the default for Win32 is 8.

Unless they recently lowered the alignment from 8 to 4 ::)

> jj, are you on a nostalgia trip?  :P

No, I won't join the push push call fraction. I am a fan of 21st century invoke & .Repeat ... .Until ecx>=123 etc :P

[TWell]

#pragma pack(show)

Code: [Select]

>bin\cl -c TestPacking.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

TestPacking.c
TestPacking.c(1) : warning C4810: value of pragma pack(show) == 8

>bin\amd64\cl -c TestPacking.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40904 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

TestPacking.c
TestPacking.c(1) : warning C4810: value of pragma pack(show) == 16



[hutch--]

> No, I won't join the push push call fraction. I am a fan of 21st century invoke & .Repeat ... .Until ecx>=123 etc

I am glad to see you are among the modern in technology, its now the mov mov mov call (do domething) ret generation. Call automation is a convenience, not a syntax. 

[hutch--]

 

I gather from the response that no-one should hold their breath waiting for anyone else to help John and Branislav in the support system for HJWASM with main include files, prototypes and help files. I wonder what has happened to the sense of collaboration that is supposed to exist in the "open sauce" community ? These guys are actually doing good development work and deserve support, not just people sucking the life out of them for whatever they can get.

[jj2007]

Hutch,

You have done an impressing job, first with Masm32, now with Masm64. While we are all happy with Masm32, very few people seem to consider working with the CrippleWare^TM Microsoft MASM64 assembler. You have put all your bets on this one - your choice.

I would like to help with alternatives, but Real Life^TM interferes a lot with my programming. Yet, I have managed to put up a modest 64-bit system, as shown in the screenshot below. Those who manage to install both Masm32 and MasmBasic can use it immediately, without bothering to install the Microsoft behemoths VS and/or SDK, without any additional libraries. It allows assembling as 64-bit or 32-bit code (see attached project: open the *.asc in RichMasm, hit F6), and it includes a powerful debug macro.

[hutch--]

> very few people seem to consider working with the CrippleWareTM Microsoft MASM64 assembler.

Strange as it is the most widely distributed assembler in the world ALA being part of VC. While it already had a full set of libraries and include files, the rest are "vapourware[TM]" in that with years of development, they still don't have a viable support system. What you cannot get with a "hand holder" is the knowledge of how Win64 works where ML64 left you with no choice on having to learn just to get it going but it is up, production capable and ready to rock 'n roll. Over 50 library modules, over 100 macros and much more to come.

It will bite the hand that feeds it but for anyone who has written low level assembler over the years, this is nothing new, having written a lot of inline assembler in my time, ml64 is a luxury in comparison, seems to have no problems at all with 256 bit AVX and when I get far enough in front I will have a look at AVX2 in 512 bit.

I have attached a development toy as I need UI code to further develop library modules and test code. It was spat out of a code generator in a few seconds. I tweaked a few bits so you could recognise it as a demo for you.

[jj2007]

It was spat out of a code generator in a few seconds. I tweaked a few bits so you could recognise it as a demo for you.

I feel honoured, Hutch

[K_F]

I agree with Tim here, 8 byte alignment is the spec for Win 64, it works correctly with ML64

I've settled for this.. a while back