News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

joke

Started by Mikl__, February 15, 2018, 02:01:17 PM

Previous topic - Next topic

aw27

Quote from: HSE on February 16, 2018, 04:40:39 AM
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)
Hi HSE,
Thank you. I thought it was a wordplay meant to divert the subject but I sticked on it.

hutch--

I have a straight forward view on macros, its driven by sheer laziness and the lack of interest in having to type the same old stuff over and over again. Then there is the functional clarity when hacking together heaps of high level code, if the code is just shoveling API calls together, why waste the effort doing manual calls to long complicated and messy API functions when you can do it with a macro that means you don't have to think all that hard on using it. Save your brain, creativity and effort for something that matters, FAST code where you will see the difference or small code if you are burdened with that problem.  :P

avcaballero

Doing subroutines for repeated codes is the right thing to do. The question is: use macros or procedures. Or at what level to use each other. Most of the time I guess it's a matter of taste.

aw27

Quote from: hutch-- on February 16, 2018, 10:49:54 PM
I have a straight forward view on macros, its driven by sheer laziness and the lack of interest in having to type the same old stuff over and over again.
In addition there are things that can only be done with macros (I had one example, defining try-except blocks).
However, macros are difficult to debug, increase the chance of subtle bugs and don't produce optimized code.
Moreover, newbies tend to use them without having a clue of what is behind - some even believe that they are part of the assembler.

It is true macros can save a lot of time and that is good, the abuse of macros is bad (in my opinion).


jj2007

Quote from: aw27 on February 17, 2018, 02:41:48 AMmacros are difficult to debug

True. On the other hand, they can make debugging a lot easier; I just had a bug that happened when reading a file into a buffer, of which there are a dozen occurrences. I found it by modifying FileRead$() so that it told me in which line of the code the error occurred. Btw an absolutely weird error: a call to FindClose trashed the local buffer with the filename (and yes, it was big enough).

Quoteincrease the chance of subtle bugs

Hand-crafted code is much more error-prone.

Quotedon't produce optimized code

That depends entirely on the macro's design.

Quotenewbies tend to use them without having a clue of what is behind

True, but using print or deb allows newbies to concentrate on the more basic stuff, like understanding what opcodes really do. You won't produce better code just because you studied the WriteFile disassembly... tools are there to be used, you don't need to understand the internals and theory of a hammer to drive a nail into the wall 8)

LordAdef

I was actually having fun!

sorry, resume  :eusa_dance:

aw27


Quote
That depends entirely on the macro's design.

I noticed, your print macro runs through hundreds of lines of macro code, then calls 2 masm32 lib files, to produce a glorious printf or writefile in the end that I could do in a couple of asm instructions.
Is this the reason for your huge executables?

Quote
Quotenewbies tend to use them without having a clue of what is behind
True, but using print or deb allows newbies to concentrate on the more basic stuff, like understanding what opcodes really do. You won't produce better code just because you studied the WriteFile disassembly... tools are there to be used,

Nobody studies the WriteFile disassembly, I never did.

Quote
you don't need to understand the internals and theory of a hammer to drive a nail into the wall 8)

ASM is not for people that does not care about the details.


daydreamer

Quote from: hutch-- on February 16, 2018, 10:49:54 PM
I have a straight forward view on macros, its driven by sheer laziness and the lack of interest in having to type the same old stuff over and over again. Then there is the functional clarity when hacking together heaps of high level code, if the code is just shoveling API calls together, why waste the effort doing manual calls to long complicated and messy API functions when you can do it with a macro that means you don't have to think all that hard on using it. Save your brain, creativity and effort for something that matters, FAST code where you will see the difference or small code if you are burdened with that problem.  :P
the coolest thing you can do with masm is to reprogram its normal mnemonics todo something else
or you can push and pop XMM regs and make it possible to emulate fluxus or Another language
I did that because I saw a tutorial on recursive 3d code that created a 3dtree, containing tree trunk/bigbranches/smallbranches inside xmm regs, that goes up each step it turns and scales down and moves vertices
fluxus is the language used for create animation inside windows mediaplayer,but it also can do some 3d procedural meshes
my none asm creations
https://masm32.com/board/index.php?topic=6937.msg74303#msg74303
I am an Invoker
"An Invoker is a mage who specializes in the manipulation of raw and elemental energies."
Like SIMD coding

jj2007

Quote from: aw27 on February 17, 2018, 05:23:05 PMI noticed, your print macro runs through hundreds of lines of macro code, then calls 2 masm32 lib files, to produce a glorious printf or writefile in the end that I could do in a couple of asm instructions.
Is this the reason for your huge executables?

Well, "huge" is what I would reserve for the 8MB Hello World proggie that QT generates. MasmBasic has currently a 26 kB overhead, which is certainly deplorable for the "I made it with 512 bytes" fans, but inside these 26 kB is the infrastructure for generating very efficient code. Here is a trivial example, printing the current time:include \masm32\MasmBasic\MasmBasic.inc ; download
uselib DateTime

.data?
sysdt0 FILETIME <>
sysdt FILETIME <>
buffer db 100 dup(?)

  Init

; ---- MasmBasic: ---
  MbTime_s:

  PrintLine "Hello World, it is now ", fTime$() ; print formatted time

  MbTime_endp:

; ---- Masm32 plus Greg Lyon's library: ---

  M32Time_s:

  print "Hello World, it is now "
  invoke GetSystemTimeAsFileTime, addr sysdt0
  invoke FileTimeToLocalFileTime, addr sysdt0, addr sysdt
  invoke DateTimeToTimeString, addr sysdt, addr buffer
  print offset buffer, 13, 10

  M32Time_endp:

  CodeSize MbTime
  CodeSize M32Time

  Inkey
EndOfCode


Output:Hello World, it is now 09:55:55
Hello World, it is now 09:55:55
25      bytes for MbTime
70      bytes for M32Time


As you can see, MasmBasic needs one line instead of five, and produces much shorter code.

You mentioned that RichMasm is kkrunched: yes, that is necessary to respect the forum's 512 kB limit for attachments; the "true" size is 145,408 - which is quite a bit, of course. But it is small when taking into consideration the over 20k lines of code. The 26k overhead may be "huge", but "exe size per line of code" is very small. For comparison, Notepad needs 179,712 bytes for performing very, very rudimentary tasks; WordPad needs 4.47 MB. Notepad++ arrives at 2.3 MB, but has neither bookmarks nor a decent search function; unusable for my taste.

hutch--

 :biggrin:

MASM32 starts with a 1k window, I doubt that absolute size matters these days and if I have a choice it would be speed over size as the file size is small enough anyway. It is always the case that you never write more than you need or less that what makes the code work well, some tolerance makes sense when it comes to the clarity of code but going down the slippery slope of "easy" generates the trash we often see today, big, slow, sloppy and buggy.

The MASM32 SDK was designed from scratch to produce small efficient code but it was also designed to be usable so it has long used macros to automate much of the unimportant stuff so that you have the time to write the serious stuff, mnemonic algorithms that deliver the performance where needed. The MASM32 "print" was not designed to be clever or sophisticated, it was designed to take the hack work out of doing ordinary things.

aw27

Quote
As you can see, MasmBasic needs one line instead of five, and produces much shorter code.
The simple fact of adding Printline adds 27KB of code and you say it produces much shorter code.  :badgrin:

Quote
Notepad++ arrives at 2.3 MB, but has neither bookmarks nor a decent search function
Notepad++ has bookmarks and the best search function we can find in text editors.
RichMasm is amazing in the eyes of its father, I can understand the sentimental part. I find it a confusing mess, though.

aw27

Quote from: hutch-- on February 17, 2018, 08:59:53 PM
:biggrin:

MASM32 starts with a 1k window, I doubt that absolute size matters these days and if I have a choice it would be speed over size as the file size is small enough anyway. It is always the case that you never write more than you need or less that what makes the code work well, some tolerance makes sense when it comes to the clarity of code but going down the slippery slope of "easy" generates the trash we often see today, big, slow, sloppy and buggy.

The MASM32 SDK was designed from scratch to produce small efficient code but it was also designed to be usable so it has long used macros to automate much of the unimportant stuff so that you have the time to write the serious stuff, mnemonic algorithms that deliver the performance where needed. The MASM32 "print" was not designed to be clever or sophisticated, it was designed to take the hack work out of doing ordinary things.

I am not talking about the Masm32 SDK, it has many useful features and in general it produces reasonably sized code.  :t
Print, Printline are from the Masmbasic I believe.

jj2007

Quote from: aw27 on February 17, 2018, 09:00:28 PMNotepad++ has bookmarks and the best search function we can find in text editors.

Its "bookmarks" are a joke, and its search function has no "matches" listbox... these are real bookmarks:

aw27

JJ,

Notepad++ has matches listbox even across all the opened documents!
It does not have bookmark list feature but there is a plugin that can do it, if we bother with that - I don't.

Notepad++ is not an RTF editor (who needs RTF for programming? Nobody had that idea before!), but it is a great programmer's editor. Since you have no idea, what Notepad++ is all about have a look here:
https://notepad-plus-plus.org/assets/images/docMap.png

It even has line numbers, imagine! Something absolutely useless in your opinion, of course.

Ah, and if you don't like the default colors (you have a great color appetite, as seen by your editor) there are lots of themes you can download for Notepad++. You can also change colors one by one if you are patient.

hutch--

I see editors as something like choosing girlfriends, I like slim racy blondes but some like buxom brunettes and everything else inbetween. If an editor does the job for you, that's all it can do, the rest is personal genius, hard work and sometimes, good luck.