joke

[jj2007]

P.S. a) Why is so good the intensive use of macros? b) MenuetOS, KolibriOS, Fasm

Because writing print str$(eax) is so much shorter (and much less error-prone) than doing it the "bare metal way".

Of course, those who create the macros must know the "bare metal" very well.

When I say masm you can also understand masm, uasm, jwasm or anything related. Particularly what I miss is a package ready to go, unzip and programming (without external needs)

We have that package already, it's called Masm32 SDK. Of course, if there was any real advantage other than addressing gigabytes of memory, then Masm64 SDK would be nice. But there is no real advantage 8)

[aw27]

Because writing print str$(eax) is so much shorter (and much less error-prone) than doing it the "bare metal way".

What I find strange in here is the devotion and commitment of some people to transform assembly language into a high-level language. Each one has its proper well established terrain.
I don't find any usefulness into print str$(eax) and Masm Basic executables are extremely oversized, much bigger than in C language, even for a simple Hello World program.

[jj2007]

MasmBasic executables are extremely oversized, much bigger than in C language, even for a simple Hello World program.

Yeah, I feel really ashamed about the 20k overhead :icon_redface:

[aw27]

Yeah, I feel really ashamed about the 20k overhead :icon_redface:

I wondered a few times what a hell do you put in there to make it grow to over 40k in a simple application that does almost nothing.
Anyway, the important thing is that you are happy.  :t

[avcaballero]

A "problem" on using many macros is that each time you use it, the macro unrolls increasing the size, an advantage on using it is that the code increases in speed.

[jj2007]

I wondered a few times what a hell do you put in there to make it grow to over 40k in a simple application that does almost nothing.

Yes, I am also deeply worried :(

For example, this one really does almost nothing:

include \masm32\MasmBasic\MasmBasic.inc         ; download
  Init 
  GetFiles *.asm                        ; put some files into the Files$() array
  SortFiles                             ; latest first
  For_ ebx=0 To Min(4, eax-1)           ; don't print them all
       PrintLine Str$(GfSize(ebx)), Tb$, GfDate$(ebx), Spc2$, GfTime$(ebx), Tb$, Files$(ebx)
  Next
  Inkey "Hello World, it is now ", fTime$(0), " on ", fDate$(0)
EndOfCode

Code Select Expand

2228    15.02.2018  14:50:33    SimpleEditor.asm
154     15.02.2018  10:28:08    NewMasm32.asm
80702   15.02.2018  10:21:01    MbGui.asm
80702   15.02.2018  10:21:01    MbGuiTmp.asm
43426   15.02.2018  10:00:07    GuiTableControl.asm
Hello World, it is now 14:55:51 on 15.02.2018

A whopping 27,136 bytes! My only consolation is that I am still a factor 500 away from a QT Hello World... but I am pretty sure it could be done with FASM macros in less lines and 1,536 bytes exe size 8)

[aw27]

lol, QT is a great multiplatform framework. Probably is not so big when we consider what it is aimed at. In other words, it is not optimized for Windows, is intended to make programmers feel as if there are no platform differences.

[aw27]

A "problem" on using many macros is that each time you use it, the macro unrolls increasing the size, an advantage on using it is that the code increases in speed.

May not increase in speed when the macro itself calls functions in libraries, as is often the case.
A simple macro like print str$(eax)  is really huge, and all it does is call msvcrt's printf in the end.

[jj2007]

(QT) is not optimized for Windows

You are a genius: Nobody so far has been able to condense the "8 MB for a hello world proggie" problem into six words :t

A simple macro like print str$(eax)  is really huge, and all it does is call msvcrt's printf in the end.

It is not "huge", and it doesn't use the CRT. See \Masm32\m32lib\stdout.asm and \Masm32\m32lib\dwtoa.asm

[aw27]

You are a genius: Nobody so far has been able to condense the "8 MB for a hello world proggie" problem into six words :t

After we compress it with kkrunchy 0.23 alpha, like your RichAsm.exe, it may not be that far apart.   
No pun intended, it is legitimated to be concerned with size.  ;)
PS: No, I am not going to unpack RichAsm.exe to know the real size, you can sleep in peace.

[HSE]

Hi Atellier!

You are a genius: Nobody so far has been able to condense the "8 MB for a hello world proggie" problem into six words :t

After we compress it with kkrunchy 0.23 alpha, like your RichAsm.exe, it may not be that far apart.   

Here "condense" means "to reduce a book, speech, statement, or the like, to a shorter form" (a problem in this case), not "to make more dense or compact" (a binary in this case)

:t

[Mikl__]

I'm saddened that my joke in FASM became the reason for the holywar

[jj2007]

Hi Mikl! Sorry for that, but don't worry, it's not holy war. José and I are just teasing each other a little bit :icon_mrgreen:

[aw27]

Hi Mikl! Sorry for that, but don't worry, it's not holy war. José and I are just teasing each other a little bit :icon_mrgreen:

In other words, we are just exchanging our points of view in a set of matters we only marginally agree.  :P

[jj2007]

Back on topic (joke): Native Compilation – Why JIT when you can CodeGen!

Micros**t has decided that JIT compiling for .NOT is mega-out, and that it would be somehow, ehm, more efficient to produce executables that are optimised for Windows. Isn't that cute?  ;)