Does my intro assembly program look okay? MASM

Question

Assignment Grading Rubric

Here is the assignment requirements and grading rubrics. Based on these elements, is there any advice for me? Thank you.

.386
.MODEL FLAT, stdcall
.STACK 4096
  ExitProcess PROTO, dwExitCode: DWORD    
.data
  sum       DWORD 10000h
  message   BYTE "Welcome to Assembly programming.", 0dh, 0ah, "You grade will be randomly assigned", 0dh, 0ah, "by the Intel 8086 processor!"
  length1   DWORD SIZEOF message                    ; SIZEOF operator returns the size of variable "message"
  lengthConstant EQU 5 + LENGTHOF message           ; Declaring a symbolic constant. LENGTHOF returns the length of variable "message"
  length5   DWORD lengthConstant                    ; lengthConstant here will eventually be replaced with result of the expression (5 + LENGTHOF message) 
  input     BYTE ?                                  ; uninitialized variable 

.code
  main PROC                     ; Start of main procedure
    mov input, 11001000b        ; Assign 200 to variable "input"
    inc length5                 ; Add 1 to length5
    INVOKE ExitProcess,0        ; Exit the process
  main ENDP                     ; End of main procedure
END main

Answer 1

Looks certainly lot more better than many SO questions, not sure where others students would be, but as far as I am concerned, you would get probably 7 or 8 out of 10, which is sort of excellent considering how grumpy I am.

Pity you didn't try also some simple task/logic on few lines, to get more bashing... ;) Also some of my remarks are probably just result of you putting up "fake" source, maybe with real one you would do even naturally better in some aspects (symbol names), as the things would have clearer purpose.

Now I would try to address those tiny details I can think of:

.data
  sum       DWORD 10000h
  message   BYTE "Welcome to Assembly programming.", 0dh, 0ah, "You grade will be randomly assigned", 0dh, 0ah, "by the Intel 8086 processor!"

I would refrain from long lines, usually 100 is reasonable limit in modern IDEs to have whole lines visible on screen, if you are in risk of ending at some projector during class, aim rather at just 80.

And I prefer, due to historical reasons of Z80 assembler line parser based on column positions, to have fixed columns for particular part of line, ie <label> <instruction> <operands> <comment> , each reasonably indented by tab so far, that usually almost all lines fit that "template". But depends whether also you will find the look more attractive to you and easier to read. I can see you used that for the comments already, so you may reconsider also operands positions (especially check lectors examples, if there are some :) ). For example those two initial data lines, the string can be naturally split at the newline control points, so it will have both shorter lines and also you will visually see how it will land on the screen:

  sum       DWORD   10000h
  message   BYTE    "Welcome to Assembly programming.", 0dh, 0ah
            BYTE    "You grade will be randomly assigned", 0dh, 0ah
            BYTE    "by the Intel 8086 processor!"

---

  length1   DWORD SIZEOF message                    ; SIZEOF operator returns the size of variable "message"

length1 - length of what? How about messageLength ... not that message itself is amazing name, but as single message in whole app that may do. Otherwise I would use rather something like txt_welcome and txt_welcome_len .

Also verify after assembly by checking listing file, if that multi line didn't break SIZEOF (I don't use that one, so I'm not sure how it works, you can also calculate occupied bytes by subtracting starting address from current position, like $ - message , at least I hope that does compile under MASM).

  lengthConstant EQU 5 + LENGTHOF message           ; Declaring a symbolic constant. LENGTHOF returns the length of variable "message"

For some reason I tend to use all-caps for EQU , as those are not symbols stemming from machine code, but just pure abstract definitions, but that's not that important, feel free to find your own style. Just be consistent.

  length5   DWORD lengthConstant                    ; lengthConstant here will eventually be replaced with result of the expression (5 + LENGTHOF message)

Not eventually, but right during assembling, before emitting the resulting machine code, ie at compile time (not linking or run-time). Overall these comments are good as tutorial explaining MASM directives, but a bit too verbose for real code comments, be more imperative in those like ; memory value = length of message+5 ; memory value = length of message+5 .

  input     BYTE ?       ; ...

Uninitialized data belong to "BSS" section, I think in MASM there's the .data? shortcut (similar to .data directive).

.code
  main PROC                     ; Start of main procedure
    mov input, 11001000b        ; Assign 200 to variable "input"

Here I have my persona quarrel with MASM syntax. When I read my source, I want to see all memory accesses easily, so I prefer the mov [input],200 with square brackets, marking the memory manipulation. It also makes that consistent with mov [edi],200 . And because in this particular case the size of datum is not obvious, I ten to explicitly declare my intent, like mov BYTE PTR [input],200 , so I don't have to check the .data section to guess what will be written into memory when I'm reviewing the code (also other common x86 assemblers like NASM or gas don't deduct data size from their definition, so they will fail to compile such code correctly without explicit size modifiers).

Same goes for the next inc instruction.

Mind you, lot of it are probably just personal preferences and bias, then again I wrote few hundreds of kilobytes of assembly source (maybe more like megabytes) in my life, so most of my bias is shaped by experience from the battle field. You may want to copy your source into several files, and try out different styles, then take few hours pause, and try to read each of them + review what they do, to see how it works for you. Keep in mind, especially with assembly coding, you will very likely spend lot more time reading your source (and looking for that !@$#@$# bug), than writing it, so make sure when you are writing it, that it reads well. :)

And about instruction comments: try to tell the missing part of story, just some example:

mov   BYTE PTR [input], 200    ; store 200 into input variable
   ;;; - not very good, describing the instruction function
   ;;; (which is obvious for assembly programmer)
mov   BYTE PTR [input], 200    ; set up maximum input length
   ;;; - the comment now displays the author intent, so the reader/reviewer
   ;;; may contemplate whether setting 200 into "input" achieves that intent

---

EDIT: and I didn't check it against your assignment, as I completely overlooked that link, as it was not part of question. Tough luck, not going to check it now, sorry. This "answer" is just style-advice.