|
No. It mostly impossible to indent in the way we do in C-like languages, because the way assembly flow works...
Like in this code... No indentation makes sense here... However I use blank lines to break the code...
raster_irq: {
lda flag
and #popup_on
bne bottom
lda $d012
cmp #raster_irq_bottom_line
bcc top
bottom:
lda #charset2
sta $d018
lda #raster_irq_top_line
sta $d012
jmp end
top:
lda #charset1
sta $d018
lda #raster_irq_bottom_line
sta $d012
end:
asl $d019
jmp $ea31
}
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
|
OP was talking about if- and for-like structures...
The only indentation here is labels vs code...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
I see no such specification.
|
|
|
|
|
Are you saying that you didn't see "do you assembler coders indent loop bodies, if-bodies / else-bodies etc. when you program such constructs in assembler?"
If you didn't see that, there is nothing more I can do for you.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: because the way assembly flow works...
No, I see no reason whatsoever why assembly flow works differently from flow in 'structured languages'.
The advantages of while- and for-loops, function definitions, if/else, switch etc. lies not in the source language keywords, but in the structured nature of your solution, which is independent of implementation language. That includes assembler.
In my student days, at a Tech University, some of the "hard engineering" departments stubbornly insisted that Fortran was The Only One Language for true engineers. This included the need for arbitrary GO TO jumps. E.g. indenting loops was meaningless, because a jump might break that loop structure. One of the professors wrote an article in the University newsletter were he fiercely attacked and ridiculed this silly idea of the Pascal programmers of moving code back and forth, right and left. That would only confuse the reader of the code, if code flow diverted from the indentation.
I don't think I have ever programmed a goto in a block structured language; it has never appeared to provide any advantage whatsoever. I am thinking in terms of structured constructs even when programming in assembler.
When I hear people arguing that assembler code "must" do it differently, my instinctive reaction is "So you want to program with GOTOs? What for??" It messes up program structure, makes maintenance more difficult, is error prone ...
I, of course, use both conditional and unconditional when assembler coding. Some people reply: "Exactly! Look at yourself: A jump instruction is the same as a GOTO!" But no; I use the jumps in a structured way, the same way that a Pascal or C compiler would generate them, such as jumping back to the top of the loop for another iteration, jump past the loop when the termination condition is satisfied, or skipping over the if clause when the condition is false, or at the end of the if clause, skip over the else clause. Jumps are frequently required at block starts (opening brace, BEGIN in Pascal) and block ends (closing brace, END in Pascal), but never in the middle of a linear sequence.
Short version: I strongly disagree that assembly program code flow differs from structured high level programming code flow. It is technically possible, as is goto-programming in Pascal or C, but you simply do not program that way,
|
|
|
|
|
I mostly agree with your view - JMP is not a GOTO equivalent, but most cases (in logically structured code) is the closing bracket of a block...
However - in assembly indentation just makes less readable IMHO...
Taking the same code sample, indentation makes it worst...
lda $d012
cmp #raster_irq_bottom_line
bcc top
bottom:
lda #charset2
sta $d018
lda #raster_irq_top_line
sta $d012
jmp end
top:
lda #charset1
sta $d018
lda #raster_irq_bottom_line
sta $d012
end:
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
No.
Probably because the early assemblers I learned on didn't support it: column zero starts were a label, column 7 started an opcode, column 15 was a parameter.
And also because it wouldn't have worked in most cases: spaghetti code is a "feature" of much assembly code (since you are trying to cram as much function into as little ROM space or processing time as possible) and you can't indent that in a meaningful way.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: column zero starts were a label, column 7 started an opcode, column 15 was a parameter.
Sounds like PLAN (ICL 1900 Assembler) which I spent several years writing.
Col 1 = label, col 7 = op code, 13 = accumulator(s), 17 = operand, 36 = comment, 73 to 80 = sequence number
The sequence numbers were vital. It was the only way of reconstructing a source program if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
|
|
|
|
|
Oh gawd yes - dropped desk were a PITA. And you had to remember to leave gaps in teh sequence numbering so you could add code later ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
jsc42 wrote: if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
That was the purpose of the sequence number. If you had punched the card deck with sequence number in col 73-80, on the Univac mainframes running Exec-8 (later renamed OS-1100), you could read in the cards in any order; the machine would sort them according to the sequence number.
That was of course no viable (although theoretically possible!) option if all cards were punched manually on a 026 card punch. I never saw anyone punching sequence numbers manually.
|
|
|
|
|
OriginalGriff wrote: spaghetti code is a "feature" of much assembly code
Yep. See my signature line. 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Of course you need JMP in assembler! You need it to skip that else clause, or return to the top of the loop. You just use it at the boundaries of logical code blocks, to implement the same semantics as the opening and closing braces of the equivalent C program.
|
|
|
|
|
Anyone who indents assembly code will be burned at the stake for such heresy.
Nothing succeeds like a budgie without teeth.
To err is human, to arr is pirate.
|
|
|
|
|
Considering gas prices (1.7€ / scm), collecting stakes to be burned is a solution.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Labels start in column 1, instructions in column 11, operands in column 21, and comments in column 41 (although the semi-colon should be in column 39).
|
|
|
|
|
YES. I indent everything, even my notes. But I did backport an habit from assembly: I align operators and operands on consecutive lines. Example
longFunctionName(arg1, argument2);
shortFunction (argument1, arg2 );
Not only it makes it easier for me to parse the code but it's a boon when used with column editing. All the coworkers who have worked on my code appreciate it too.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
No, of course not. Assembler was supposed to be hard to read, nothing should make it easier!
I also didn't indent FORTRAN - but then it didn't lend itself to that.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
The FORTRAN I used back in the day had everything in specific columns. So yeah, no indentions.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Lots of Fortran programmers never knew: In cols 7 to 72, all spaces were insignificant. You could write GOTO or GO TO, COMM ON and SUB ROUTINE.
Furthermore, no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123"
The last Fortran I touched was a Fortran77 implementation. During the design discussions for Fortran77, with each proposed extension crazier than the other, one of the old gurus (Dijkstra?) remarked that "I do not know what programming languages will look like in year 2000, but they will be named Fortran!" When I stumbled across Fortran 2011, my immediate reaction was: "You were just so right, old Master!" I guess that Fortran of today both have significant spaces and reserved words. But I wouldn't be sure of it without checking the language specification. 
|
|
|
|
|
trønderen wrote: no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123"
Oh barf.
Software Zen: delete this;
|
|
|
|
|
I also used Fortran77 in tech school. You're right, I don't recall them saying anything about spaces being ignored in those columns.
One of my cousins created (or co-created, I don't remember) PDE2D using Fortran. The latest Windows version uses v11, and the Linux and Mac version use various flavors of GNU GFortran.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
The last time I wrote assembly code was on an XT box (8088 processor) using edlin. I barely remember what I ate for dinner yesterday, much less code from 40 years ago. I do remember loving to code that close to the hardware.
And thanks for reminding me that I'm old as dirt. 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Never, always been a tab then the op code. Labels start in the first column.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Hmm. My last significant bit of assembly language was an OS/2 device driver written in Intel assembly language, flat memory model (yay!).
There were a few places in the driver that implemented algorithms I originally (pseudo)coded in C. Those places tended to use indentation that resembled the original C.
Indentation was not my practice throughout.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
