Author Topic: #IF  (Read 470 times)

Biterider

  • Member
  • **
  • Posts: 207
  • ObjAsm32 - ObjAsm64
    • ObjAsm64
Re: #IF
« Reply #15 on: June 16, 2018, 08:00:02 PM »
Hi habran
If you can provide the exe, I'll test it asap.
Biterider

habran

  • Member
  • *****
  • Posts: 1168
    • uasm
Re: #IF
« Reply #16 on: June 16, 2018, 10:00:49 PM »
OK, here it is
however, it is just for your testing
The official release will be uploaded if this one is OK.
Cod-Father

jj2007

  • Member
  • *****
  • Posts: 8507
  • Assembler is fun ;-)
    • MasmBasic
Re: #IF
« Reply #17 on: June 16, 2018, 11:45:43 PM »
All code written for the new UAsm version will be incompatible with ML, of course...

Here is another workaround:
Code: [Select]
include \masm32\include\masm32rt.inc

defined MACRO arg
  ifdef arg
defret=arg
exitm <1>
  else
defret=0
exitm %0
  endif
endm

.code
start:
  if defined(RECT) and defret GE 16
print "RECT is defined", 10
  else
print "RECT is undefined", 10
  endif
  if defined(bla) and defret GE 16
print "bla is defined", 10
  elseif defret
print "bla is defined, its value is "
print str$(defret), 10
  else
print "bla is undefined", 10
  endif
  bla=1
  if defined(bla) and defret GE 16
print "bla is defined", 10
  elseif defret
print "bla is defined, its value is "
print str$(defret), 10
  else
print "bla is undefined", 10
  endif
  inkey

  exit

end start

habran

  • Member
  • *****
  • Posts: 1168
    • uasm
Re: #IF
« Reply #18 on: June 17, 2018, 12:40:16 AM »
JJ, I agree with you, even though that change would affect only "if Symbol and" :biggrin:
The problem would appear when headers would work only with UASM.
If Biterider is happy with that macro of yours I am happy to.
It is better to use macro which can be shared with masm.
However, the macro could be maybe done even more sophuckenphisticated ;)
Cod-Father

Biterider

  • Member
  • **
  • Posts: 207
  • ObjAsm32 - ObjAsm64
    • ObjAsm64
Re: #IF
« Reply #19 on: June 17, 2018, 06:57:39 AM »
Hi
I'll do the testing tomorrow morning.
Biterider


Biterider

  • Member
  • **
  • Posts: 207
  • ObjAsm32 - ObjAsm64
    • ObjAsm64
Re: #IF
« Reply #20 on: June 17, 2018, 05:51:00 PM »
Hello
@Habran: thanks for the exe. I tested it successfully. I tried other combinations like
Code: [Select]
if 1 and defined(Symbol) and (Symbol eq 1)   ;Symbol not definedand confirmed that it is just a hack for only 1 situation.  ;)

If we want to implement something like an "early return of conditional sentences", when the final logical outcome in a given analysis state is known, without having to check the remaining conditions, more work has to be done. BTW, HLLs do it that way.

Another example with “or” is
Code: [Select]
if 1 or (Symbol eq 1)This expression should be TRUE, even if symbol is not defined.
 
The other side of the coin are the arguments of JJ & Habran: compatibility. ML does not work that way. It strictly analyse each condition to finally get the result.
I don’t think we will brake existing software, but if we write new one, like the header file translation, ML will not be able to assemble it because of these new features.
ATM, I do not know which way is the best. Maybe someday we'll have to leave ML behind and evolve. Other opinions or ideas?

Biterider

LiaoMi

  • Member
  • **
  • Posts: 242
Re: #IF
« Reply #21 on: June 17, 2018, 06:19:15 PM »
Hello,

ToutEnMasm solved this problem by a simple definition in "Full SDK Include Project"

Code: [Select]
_WIN32_WINNT equ 00000602h
NTDDI_VERSION equ 06020000h
WINVER equ 06020000h

_WIN64 equ 1
_INTEGRAL_MAX_BITS equ 128 ;-------------
_MSC_VER     equ 1500   ;win xp sp2  reponse vc++
_WIN32_IE equ 800h ;internet explorer 7
_MSC_FULL_VER equ 150021022
__midl equ 0
_WIN32_FUSION equ 0
_WIN32 equ
DBG equ 0 ;ou 1
__GOT_SECURE_LIB__ equ 1 ;a chercher
;_WIN32 equ 1
__RPCNDR_H_VERSION__ equ 100h ;-- ?
IFDEF _WIN64
PPVREGISTER TEXTEQU <R11>
ELSE
PPVREGISTER TEXTEQU <edx>
ENDIF

;----------------------------------------------------------
_X86_ equ 1
__STDC__ equ 1
ISOLATION_AWARE_ENABLED equ 0
_DBG_MEMCPY_INLINE_ equ 0
_MSC_EXTENSIONS equ  1    ; DUMMYUNIONNAME vide
OEMRESOURCE equ 1 ;various resource system IDC_..
_M_IX86 equ 1 ;x86 C compiler target architecture ,no masm
;-----------------------------------
;WINAPI_PARTITION_APP equ 1    ;sdkddkver
;_WIN32_WINNT_WINBLUE equ 603h ;c++
;NTDDI_WINBLUE equ 6030000h ;c++
;----------------------------------
include sdkddkver.sdk ;define _WIN32_WINNT and _WIN32_IE
;----------------- change NTDDI_WINXPSP3 as needed -----------------
NTDDI_WINLH equ NTDDI_WIN2K ;CertSetCertificateContextProperty Windows 2000 Professional minimum system required
_WIN32_WINDOWS equ _WIN32_WINNT_WINXP
_WIN32_WCE equ _WIN32_WINNT_WINXP
WINXP equ NTDDI_WINXP ;minimum xp demandй par rpcdce.h
NTDDI_WXP  equ NTDDI_WINXPSP1
NTDDI_XPSP2 equ NTDDI_WINXPSP2
NTDDI_WIN2003 equ NTDDI_WIN2K ;pas sur
_NT_TARGET_VERSION_WIN7 equ _WIN32_IE_WIN7 ;Windows 7 minimum

This is quite enough to forget about this variable  :biggrin: Or are there any hidden features that I have overlooked?

jj2007

  • Member
  • *****
  • Posts: 8507
  • Assembler is fun ;-)
    • MasmBasic
Re: #IF
« Reply #22 on: June 17, 2018, 08:25:46 PM »
ToutEnMasm solved this problem by a simple definition in "Full SDK Include Project"

This was my spontaneous reaction, too, but:

@JJ: the windows header files is a house of cards that builds heavily upon the existence (definition) of symbols. If we define all of them, the result will not be the same, since we will include things we are not interested in. In case we do, we accept that all generated inc files will need to be corrected by hand (~2000 files for Win10)

LiaoMi

  • Member
  • **
  • Posts: 242
Re: #IF
« Reply #23 on: June 17, 2018, 09:14:08 PM »
ToutEnMasm solved this problem by a simple definition in "Full SDK Include Project"

This was my spontaneous reaction, too, but:

@JJ: the windows header files is a house of cards that builds heavily upon the existence (definition) of symbols. If we define all of them, the result will not be the same, since we will include things we are not interested in. In case we do, we accept that all generated inc files will need to be corrected by hand (~2000 files for Win10)

Hi jj2007,

 I also thought so, but the question is, do you think a programmer needs all these definitions in assembler? Most structures can be used without configuration conditions. All these flags are needed only for a high-level compiler, in this case, we can get the two strategies - First, we leave some basic definitions, after this we delete all unnecessary definitions. Since I personally dont need these conditional definitions in my code, I decide what I need to add and what not, there is a direct link to the object that I need in my code, nothing else is needed.
 Of course my opinion may be wrong, I dont pretend to have absolutely correct understanding of the problem, because I dont know C++ well  :redface:

Biterider

  • Member
  • **
  • Posts: 207
  • ObjAsm32 - ObjAsm64
    • ObjAsm64
Re: #IF
« Reply #24 on: June 17, 2018, 09:33:30 PM »
Hi LiaoMi
You can go this way, but it will be really hard to keep the set of .inc file updated. With each major Windows update you will need to go through the whole process again ans again. In my opinion, we need an automatic tool that processes the ~2000 header files. Minimal intervention can not be avoided, but not more than that.  :redface:

Biterider

Vortex

  • Member
  • *****
  • Posts: 1806
Re: #IF
« Reply #25 on: June 17, 2018, 09:39:21 PM »
Sadly, M$ did everything to obfuscate those SDK header files.

LiaoMi

  • Member
  • **
  • Posts: 242
Re: #IF
« Reply #26 on: June 17, 2018, 10:43:25 PM »
Hi LiaoMi
You can go this way, but it will be really hard to keep the set of .inc file updated. With each major Windows update you will need to go through the whole process again ans again. In my opinion, we need an automatic tool that processes the ~2000 header files. Minimal intervention can not be avoided, but not more than that.  :redface:

Biterider

Hi Biterider,

thats right, I assumed that the basic structure does not change so quickly and I did not consider the idea of a universal solution, It would be convenient to make a parser of such conditions, which shows a table with parameters, similar as it is done in cmake

What to do with these data after processing?  :icon_rolleyes:

habran

  • Member
  • *****
  • Posts: 1168
    • uasm
Re: #IF
« Reply #27 on: June 17, 2018, 11:08:29 PM »
I totally agree with you Biterider :t
It is not a big deal to implement such features in UASM because it is so flexible and ALIVE, however, headers should be flexible as well and that is why we should use macros for that job, which can be implemented in masm
 as well. JJ is on the rite track and maybe some other macros experts could get involved ;)
 
BTW, correct behaviour of the assembler should be to stop at and after first expression if it is negative and I would like to correct UASM in that matter. That is one of masm "features" which we can avoid.
We can still exclude it with a strict masm compatibility. Opinion about that matter would be appreciated 8)
« Last Edit: June 18, 2018, 12:16:39 AM by habran »
Cod-Father

Biterider

  • Member
  • **
  • Posts: 207
  • ObjAsm32 - ObjAsm64
    • ObjAsm64
Re: #IF
« Reply #28 on: June 19, 2018, 06:09:55 AM »
Hi
Good news... at least for now :biggrin:
I've listed all the files included, starting with Windows.h, and came up with a total of about 200 files, which is roughly the same number of files supplied by h2incX (v0.99.20).
Much less than the 2000 files located in the header include directories. 200 files can be managed if the logic needs to be changed to meet the requirements of masm.

Nevertheless, I would suggest to keep on the UASM logic optimization.

Biterider

habran

  • Member
  • *****
  • Posts: 1168
    • uasm
Re: #IF
« Reply #29 on: June 19, 2018, 08:09:24 AM »
Great :t
Does that mean that you want to keep that change in UASM which I implemented?
Cod-Father