Author Topic: High Level Language in MASM  (Read 74787 times)

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #60 on: November 23, 2012, 11:03:18 PM »
:biggrin:

DAMN, I knew it would happen !!!! HOLY WAR !   :P

Not to worry, Hutch...  I learned a long time ago to never argue with a zealot...
But I still get a kick out of prodding them once in a while.


hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5251
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #61 on: November 23, 2012, 11:36:04 PM »
 :biggrin:

Yeah, particularly if you use a sharp stick.  :P
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

jj2007

  • Member
  • *****
  • Posts: 8209
  • Assembler is fun ;-)
    • MasmBasic
Re: High Level Language in MASM
« Reply #62 on: November 24, 2012, 01:05:30 AM »
This is C...
Code: [Select]
if (Myflag)
  puts("flag was set\n hooray");
else
  puts("flag was clear");

FYI  they are two separate languages.

Soooorry  :redface:
So C++ couts, and C puts text on the screen. Interesting.
And you could have two lines without {brackets} in C, like this? I mean, the C compiler understands that the two lines between if and else belong to the same scope?

Code: [Select]
if (Myflag)
  puts("flag was set");
  puts("hooray");
else
  puts("flag was clear");

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #63 on: November 24, 2012, 02:12:09 AM »
So C++ couts, and C puts text on the screen. Interesting.
And you could have two lines without {brackets} in C, like this? I mean, the C compiler understands that the two lines between if and else belong to the same scope?

Code: [Select]
if (Myflag)
  puts("flag was set");
  puts("hooray");
else
  puts("flag was clear");

No it doesn't... you would need brackets on the first part but not on the second.  However it's much easier to do it the way I showed in my origial example... since you have two puts statements you can simply merge the strings and have one call.

You do this...
Code: [Select]
if (Myflag)
  {
     puts("flag was set");
     puts("hooray");
  }
else
  puts("flag was clear");

The thing is you are revealing that you don't actually know enough about these languages to offer a valid critique.  Why don't you take in a couple of tutorials...  like THIS ...Play with the code, try the examples and then see what you think, once armed with real information?
 
Most of the outspoken opposition I hear to various programming languages comes from a natural human tendency to react to difference in a negative way.  I'm here by invitation to do two things... First, to offer up Easy Build (in the IDE forum) for beta testing and Second to learn a little ASM.  I look at some of the code snippets here and find myself naturally going "Oh WTF is THIS???" but through experience learning new languages and procedures, I know this is just a reaction to difference... its a semantically different way of expressing the same instructions to the CPU and not a flaw at all. 
 
There are many many cases of "distinction without difference" in this world... C uses puts(), C++ uses cout, Pascal uses write(), BASIC uses print, and so on... in the end they're all calls to the API's WriteConsole() function, which is really the only way to get something onto a console screen... The semantics employed in doing that are unimportant.  This truly is disctinction without difference and to criticise any one as being worse than the others is a fools errand.  In the end all you're really saying is "I don't understand this and it scares me".
 

jj2007

  • Member
  • *****
  • Posts: 8209
  • Assembler is fun ;-)
    • MasmBasic
Re: High Level Language in MASM
« Reply #64 on: November 24, 2012, 03:57:48 AM »
C uses puts(), C++ uses cout, Pascal uses write(), BASIC uses print, and so on... in the end they're all calls to the API's WriteConsole() function, which is really the only way to get something onto a console screen... The semantics employed in doing that are unimportant.  This truly is disctinction without difference and to criticise any one as being worse than the others is a fools errand.  In the end all you're really saying is "I don't understand this and it scares me".

Hi Tater,

No offense meant - but I do understand C, and I am not scared, just amused. I know that you can merge the two lines, but I also know that in order to squeeze in one more instruction, you must revert to {ugly brackets} that you so kindly made disappear by joining the two puts statements.

And semantics do matter. Print and Write are user-friendly, cout and puts aren't. They reflect the attitude of C coders who say, more or less openly, "you hobby coders with your BASIC spaghetti code and GOTOs all over the place, do not speak up when professionals are around" (I haven't used any GOTO in the last 25 years). Many C coders have similar "respect" for assembly coders, they see them as freaks who have missed the train etc...

My heart pressure regularly increases when I am confronted with "professional" products coded in C, like AcroRead or Flash or Mozilla, and they crash right in my face, or they drive the CPU to 99% because a team of arrogant coders is too lazy to read bug reports, or is helpless overwhelmed by their code base dispersed over a Million tiny *.cpp, *.c and *.h files. Should I be impressed by Windows 7? Wow, it works! The richest and biggest software company in the World has finally succeeded to deliver an OS that does what the userbase wants. Oh my god, miracles happen... no, really, I am not scared of C code. Except when I have to suffer from the results ;-)

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #65 on: November 24, 2012, 05:27:58 AM »
No offense meant - but I do understand C,

All evidence to the contrary not withstanding.

Quote
And semantics do matter. Print and Write are user-friendly, cout and puts aren't.

Pascal ... write("This is a test");
C ... puts("This is a test");
C++ ...  cout << "This is a test";
Basic ... print "this is a test"

Seriously...  if petty differences annoy you to the point of hatred, I think we're done.


hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5251
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #66 on: November 24, 2012, 08:06:39 AM »
if there is one beef I have with C it is strong typing, too many years of assembler where the only factors is size not type. I understand why it is required in a portable language as you have hardware differences from one platform to another which effectively gives you different sizes for a given variable type but it comes at the price of confusing many folks that try and learn assembler programming where the only factor is size.

This is the main reason why I have never gone that way with MASM, there have been many attempts over the years to straight jacket MASM with C style data naming and typing but it always came at the price of obscuring one of MASM's main advantages, always knowing the size of the data and how this factor works directly with registers.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #67 on: November 24, 2012, 11:02:41 AM »
if there is one beef I have with C it is strong typing, too many years of assembler where the only factors is size not type. I understand why it is required in a portable language as you have hardware differences from one platform to another which effectively gives you different sizes for a given variable type but it comes at the price of confusing many folks that try and learn assembler programming where the only factor is size.

This is the main reason why I have never gone that way with MASM, there have been many attempts over the years to straight jacket MASM with C style data naming and typing but it always came at the price of obscuring one of MASM's main advantages, always knowing the size of the data and how this factor works directly with registers.

Hi Hutch...
I find it rather amusing that you think C is typed too strongly, when one of the concerns in the language is that variable typing can be misused through pointers.

Without knowing for certain I believe C became typed very early in it's inception as a means of detecting programming errors such as trying to stuff an int (32/64bits) into a char (8bits) and so on.  While it is still mainly a size and signed vs unsigned issue, there have been many times when the compiler has helped me catch serious mistakes by erroring off when I misused a variable. 

Also there are different storage formats... ints are obvious, they're simple copies of registers, float and double are not so obvious since they are formatted into groups of 32 bit (or 64 bit) values for sign, exponent, integer and decimals, etc.  The real bogeyman is structs, coder defined blobs of memory where misuse could result in severe data corruption which, as I'm sure you can guess, is strongly undesirable... "Ok, how the heck does this thing think we have 23823904857 chrome plated skyhooks in stock?" and such.

ASM affords more lattitude, but it also places the onus upon the programmer to make sure that data is manipulated correctly. Get it wrong and it will happily do it wrong.  It is thus (IMO) more flexible and more dangerous, at the same time. 

Moreover; given that the relative skills of ASM vs C programmers covers a gap roughly equivalent to that between C and Java... I'd have to suggest that perhaps we should be glad of that.  (If only I had a dollar for every time I've had to explain why we free memory in C to a java programmer...  ;)  )

No, I don't think MASM (or any other assembler) should be made to be more like anything else... in fact one of my beefs with compiler development is that people do try to create tools that are "like _____ " when in fact they should focus on the strengths and improvement of what they've got.  Similarity does not breed innovation and progress. Diversity does.

jj2007

  • Member
  • *****
  • Posts: 8209
  • Assembler is fun ;-)
    • MasmBasic
Re: High Level Language in MASM
« Reply #68 on: November 24, 2012, 06:52:51 PM »
Also there are different storage formats... ints are obvious, they're simple copies of registers, float and double are not so obvious since they are formatted into groups of 32 bit (or 64 bit) values for sign, exponent, integer and decimals, etc.  The real bogeyman is structs, coder defined blobs of memory...

MASM has all the requisites to avoid this kind of problems.

include \masm32\MasmBasic\MasmBasic.inc   ; download
.data
MyQword   dq 123456789012345678
MyDword   dd 123456789
MyWord   dw 12345
MyByte   db 123
MyReal4   REAL4 1234567890.12345678
MyReal8   REAL8 1234567890.12345678
MyReal10   REAL10 1234567890.12345678
MyRect   RECT <12, 34, 56, 78>       ; a coder defined blob of memory

   Init
   PrintLine Str$("Qword: \t %i", MyQword)
   PrintLine Str$("Dword: \t %i", MyDword)
   PrintLine Str$("Word: \t %i", MyWord)
   PrintLine Str$("Byte: \t %i", MyByte)

   PrintLine Str$("Real4:   \t %If", MyReal4)
   PrintLine Str$("Real8:   \t %If", MyReal8)
   PrintLine Str$("Real10: \t %If", MyReal10)

   ; PrintLine Str$("Rect:     \t %i", MyRect)   ; Error A2049: Invalid instruction operands
   PrintLine Str$("Rect:     \t %i", MyRect.left)
   PrintLine Str$("Rect:     \t %i", MyRect.bottom)

   fldpi   ; load PI into FPU
   PrintLine Str$("PI on FPU: \t %If", ST(0))
   fstp MyReal8   ; store ST(0) to memory as float
   movlps xmm0, MyReal8
   PrintLine Str$("PI as xmm: \t %If", f:xmm0)

    Inkey
   Exit
end start

Output:
Qword:   123456789012345678
Dword:   123456789
Word:    12345
Byte:    123
Real4:           1234567936.00000000
Real8:           1234567890.12345672
Real10:          1234567890.12345678
Rect:            12
Rect:            78
PI on FPU:       3.14159265358979324
PI as xmm:       3.14159265358979312

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5251
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #69 on: November 24, 2012, 09:04:47 PM »
CommonTater,

Probably the real difference is how the data is described, strong typing depends of the prototypes where size casting alone means you are dependent on the documentation to know if a single variable is a handle, signed or unsigned integer, pointer, structure address etc ...

I am old enough to remember C that was far more loosely typed and you could write it more like untyped MASM but progressive demand for safer code meant ansi89 then 99 supported stronger typing but fortunately for experienced C programmers they could type cast a variable as another data type if necessary.

In my own case i would rather something that crashed in development so I could fix it then rather than climbing through a mountain of safety measures to find out why. You will probably laugh at this but I prefer to write "suicide" code that really will go bang if you get it wrong because it does not leave you guessing if something is wrong. It forces onto you the discipline of getting it right every time.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #70 on: November 24, 2012, 10:28:26 PM »
I am old enough to remember C that was far more loosely typed and you could write it more like untyped MASM but progressive demand for safer code meant ansi89 then 99 supported stronger typing but fortunately for experienced C programmers they could type cast a variable as another data type if necessary.

My own programming history comes from strongly typed languages... first several incarnations of Basic in the late 70s to mid-80s, then a couple of  flavours of Pascal running up to 2004  when I switched to C.  So my history is largely in strongly typed languages.  Past forets into ASM have all been utilitiarian, where I needed to do something the language couldn't. 

Quote
In my own case i would rather something that crashed in development so I could fix it then rather than climbing through a mountain of safety measures to find out why. You will probably laugh at this but I prefer to write "suicide" code that really will go bang if you get it wrong because it does not leave you guessing if something is wrong. It forces onto you the discipline of getting it right every time.

As it turns out we agree on this point... although I'm sure our experiences of it are somewhat different.  I definately want my code to fail while I still have it contained and under my control....

I just love it when the compiler catches me messing up. It saves me a ton of trouble and always gives me a line number for reference.  Having never written a program of any size that didn't spit out at least one compiler error,  I can well imagine the chaos if this didn't happen. 

Run time errors present an entirely different challenge... alpha testing usually shows up a lot of the worst problems but in any code more complex than "Can you guess my number" there is bound to be at least one subtle error that won't show up until your code gets out into the wild.  (Hense the Beta phase of Easy Build.)

We can see changes in the industry because of so called "type safe" languages, garbage collectors, etc.  The new trend is to trust the compiler, releasing practically untested code and then fixing the problems as they are reported; essentially using your own customers as alpha testers. While this does let you be far more prolific with your keyboard it certainly isn't leading to safe or stable code. 

But then what do we expect in a world that wants it NOW and at "deep discount" prices to boot.

dedndave

  • Member
  • *****
  • Posts: 8779
  • Still using Abacus 2.0
    • DednDave
Re: High Level Language in MASM
« Reply #71 on: November 25, 2012, 01:52:20 AM »
that's really the difference between assembly programmers and those of all other languages
we are aware that it is easier to screw up, and prefer to keep tabs on it, ourselves   :biggrin:
if you don't want to take that extra measure, assembler isn't for you

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #72 on: November 25, 2012, 02:01:05 AM »
that's really the difference between assembly programmers and those of all other languages
we are aware that it is easier to screw up, and prefer to keep tabs on it, ourselves   :biggrin:
if you don't want to take that extra measure, assembler isn't for you

Agreed! 

I don't mind going the extra inch, in fact I probably already do it as a routine matter of general precaution.


nidud

  • Member
  • *****
  • Posts: 1446
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #73 on: November 25, 2012, 04:19:28 AM »
If people chose to write in their own native language in this forum (or create a new language as they go along) it will generate some problems with regards to communication in general. This is the reason why a specific language is used. Not because the language itself is superior, but because history made it so. This thread is about MASM which has it’s own history.

Quote
Version 6.0, released in 1992, added high-level programming support and a more C-like syntax.
Quote
It incorporates conveniences of high-level languages while offering all the traditional advantages of assembly-language programming.
MASM is maintained by Microsoft, but since version 6.12 has not been sold as a separate product, it is instead supplied with various Microsoft SDKs and C compilers. Recent versions of MASM are included with Microsoft Visual Studio.
This means that the ocean is still open, so you don’t have to use the Panama or Suez canal, you can still go (or code) around if you chose to do so.

Quote
Loop-Generating Directives
The high-level control structures generate loop structures for you. These directives are similar to the while and repeat loops of C or Pascal, and can make your assembly programs easier to code and to read.
Easier to code is one thing, but the most important thing is of course to enable OTHER PEOPLE to be able to read your code.

I know this is the wrong place to do this, but since I already have implemented some changes to the hll section to make my assembly programs easier to code and read, I may ass well share some of this progress.

The first thing I removed was the FUNC() and CStr() macros, since these were the most frequently used. For portability reasons I also target the names of the registers, so RAX will now expand to AX, EAX, or RAX.

The prologue and epilogue definitions will make it possible to make portable source in ASM:
Code: [Select]
IOCreateSource proc
    .if IOOpenSource("w+")
        invoke IOOnCreate,fp_src,option_src
        invoke fclose,fp_src
        mov rax,1
    .else
        invoke IORemoveTemp
    .endif
    ret
IOCreateSource endp

This code will compile in all memory models (tiny, small, compact, large, flat, 64), in C, Pascal, Stdcall, and also Fastcall. The norm will be 32/64-bit, but since I’m a bit old fashioned, I also include the 16-bit stuff (as MASM does).

The size of integer is size_t (from C), and I think MS uses IWORD for signed values? The RAX definition was used in VC a long time before 64-bit was around (for AX and EAX), and now used in 64-bit.
Code: [Select]
IOOnCreate proc uses rsi rdi rbx fp:ptr S_FILE, ftype:size_t
The result looks like this:
Code: [Select]
    .if ftype == SOURCE_C
        invoke fprintf,fp, addr cp_head,
            "/*", addr file,
            " *", addr identifier,
            " *",
            " *",
            " *", rbx, rdi, rsi,
            " */\n\ntypedef unsigned short WORD;"
    .elseif ftype == SOURCE_ASM
        invoke fprintf,fp, addr cp_head,
            ";", addr file,
            ";", addr identifier,
            ";",
            ";",
            ";", rbx, rdi, rsi,
            "\ninclude clib.inc\n\n.data"
    .endif
The C code will include function calls like this:
Code: [Select]
            " *", getmnd(), getday(), getyear() - 2000,
With regards to implement C in assembly, I think it would be much better to implement asm { } in C instead. :P

frktons

  • Member
  • ***
  • Posts: 491
Re: High Level Language in MASM
« Reply #74 on: November 30, 2012, 10:09:50 AM »
Woauiextpd!!!!!

I can't believe it. We've done it again.  :lol: