I hesitate to criticize but...

I would argue that the before and after code are equally well structured
and that structuring is much more than meaningful labels and indenting.

True, the structure is more obvious but (for example) how much of that is indenting?

I think it's misleading to suggest that one is spaghetti code and one is not.

Explicit structure, using higher level macros such as FOR and WHILE, must be an advantage?

I'm not disputing that.

Agreed. With an IF...ELSE...END_IF for example (or most of the others), the resulting machine code will be the same, because you already had the structure before using the structure macros-- they just make it much more clear. I had been using indenting most of my 6502 years (decades), and white space to visually group the various actions. The structure macros didn't change that either, but they do eliminate the need for a lot of the labels, and they use clearer structure-control words. It's very difficult to come up with meaningful, unique branch label names that are short enough to fit in the left margin and not interfere visually with the program body.

And of course the program structure macro set doesn't need to be limiting. If you need a structure that's not there, you can write it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I suppose if you hadn't mentioned spaghetti code
I'd call it a semantic quibble, the source does have
a better structure.

I'd still argue that's misleading.

You refer to the "original version" as unstructured
then give a "structured version" even though the
stucture of the underlying code is exactly the same.
you're implying that making the structure more explicit
is the same as structuring the code better.

If you took actual spaghetti code and prettyed it up
in a similar fashion it wouldn't improve the structure.

You have a point, and it may lead me to give the article some needed improvement. Besides making the structure more obvious however, part of the goal is to make the programmer think in terms of structures early in the process and develop better programming habits. In that situation, the machine code produced probably won't be the same. I emphasized the "sameness" (is that a word?) to mean that the macros don't make you give up the performance you use assembly language for, or any tightness of code.

It was not the point of the article to do a lengthy treatise on structured programming philosophies, but perhaps more should be said about it, or at least I should find a good article that's already on the web to link to. (Can you recommend some good ones?) In the article on large 16-bit look-up tables for superfast, accurate trig, log, and other functions, I did explain what makes scaled-integer math quite well suited for most technical applications, since I myself had to be convinced early on.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Clearly there is a huge element of taste here.

My personal preference is to have clean uniform columns (and I like the uniform 3-letter mnemonics for 6502). It makes for compact reading and lets me quickly hunt down what I am looking for without having to use search. Sometimes paper printout is the best way of analysing the program.

Having then a set of coloured lines in the left margin would then be a quick guide yet unobtrusive to the eye.

Much of the work I did was on old embedded system where new hardware was completely out of the question and the customer, who is always right, wanted more functionality and faster performance. Structure was the first to suffer and all ugly tricks were used to shoehorn in new code. I can still remember some truly horrific code that was a scary as it was fast. Indentations would simply implode for such code.

It is from this background that I proposed a tool in the IDE that visualises zeropage pressure.

I like the 3-letter ones too, as opposed to other processors' varying-length mnemonics. I give macros names that are not three characters long, making them an instant give-away that they're macros.


That would be a good tool, but if we can ever get our 65Org32, the whole 4 gigaword address space will be in zero page (or whould I say direct page).

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Some of the 65C02 mnemonics are four characters where the fourth is a bit number: SMB0, RMB1, BBS2.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

I almost mentioned those, but I've never actually had occasion to use those instructions. They are attractive, but I would mostly want to use them in I/O, but I've never had the I/O in ZP. The 816's ZP (direct page) can be moved anywhere in the first 64K of memory space, but it doesn't have RMB, SMB, BBS, or BBR. It does have BIT and TSB and TRB like the 65c02 does which although not quite as slick, have more addressing modes.

For RMB, SMB, BBR, and BBS, I think I would prefer that the assembler take the bit number from the operand list (which you could do with a macro). Then if you decide you have to swap a couple of bits in the hardware before going to production for example, only the constants used in the operand list change, and only where they are defined. You would not have to go through and search for and change the mnemonics.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

A reasonable position, but I've just been wrestling with this in connection with developing an alternate set of "instruction" macros for the 65Org16b (EE's effort is formidable - 750K worth of macros so far! I'm aiming for something a little more compact )

The issue for me came up with that barrel shifter. Is it better to have an instruction like:



or one like:



A problem with the first form is that because the value "#4" really isn't a separate byte in the assembled code but part of the opcode itself, its value has to be known before the opcode can be stored. But users would expect "#4" to act like all other immediate mode instructions, eg., allow forward reference (it might not be common, but it should be possible).

There's also the issue of what to do if "#x" turns out to be outside the range 0-15. Silently truncate? Declare an error?

The second form eliminates both those problems. The mnemonic itself declares what the opcode bits should be, and it becomes impossible to use an out-of-range value (at least not without causing an easily-diagnosed complaint from the assembler).

I decided to go with the second form after thinking about it for a few days. It occurs to me now that it would be possible (at least with some assemblers *ahem*) to write yet another macro that looked like the first form and expanded to the second, for those that wanted to do so.

These links may help some not previously familiar with my monkeyworks:
65Org16.b Core Intro & Credit's
65Org16.b Core v2 Spec's

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Same here.


I recently added support for these to the simple assembler included in Py65:


It includes the bit number in the mnemonic as shown above. I figured this was the most straightforward thing to do since that's how they are listed in the W6502S datasheet (Table 5-2 "W65C02S OpCode Matrix") and it didn't introduce a new operand syntax. Many assemblers don't support these instructions at all.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

The Rockwell microcontroller chips like the R6501 and R6541 have built in VIA/ACIA modules that have their control registers on zero page which makes these instructions very useful. Also by default these chips can only access a 4K ROM memory space so using them would keep code compact.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs