New productivity upload: X16 Edit - a text editor

[Stefan]

Bringing clarity to code by lots of comments is not the Clean Code way of doing things, apparently. Comments have the disadvantage of being ignored by the assembler or compiler. Keeping them up to date is a manual process. And all manual processes will fail

Good labels are a better option.

The advantage of extracting small functions into macros is that you get better abstraction in higher level functions. In my example above, the function "clear_screen" contains mostly macro calls. It's possible to understand what they will do without looking at the macro. You get the big picture very quickly. And if you are interested in the details, you may look at the macro definition.

That said, I've never tried to program anything in this fashion. It would be interesting to do that.

Edited October 3, 2021 by Stefan

[Scott Robison]

Another huge (IMO) benefit if macro based assembly is to avoid copy and paste programming. Say you have a number of functions to load different files. So you have JSR LOAD_FILE_X and JSR LOAD_FILE_Y and each of these are called only once. The code is practically identical in each. Why not wrap it in a macro?

!macro LDVFILE .file, .len, .addr {
            LDX #0 ; ram block for file name
            LDA #^.addr    ; ram block for load address
            JSR JSETBNK    ; load to bank ^.addr from file named in current bank

            LDA #.len ;LENGTH OF FILENAME
            LDX #<.file
            LDY #>.file
            JSR SETNAM ;SETNAM A=FILE NAME LENGTH X/Y=POINTER TO FILENAME

            LDA #$02
            LDX #$08
            LDY #$00
            JSR SETLFS ;SETFLS A=LOGICAL NUMBER X=DEVICE NUMBER Y=SECONDARY

            LDX #<.addr  ;LOW BYTE FOR LOAD ADDRESS
            LDY #>.addr  ;HIGH BYTE FOR LOAD ADDRESS
            LDA #$00
            JSR LOAD ;LOAD FILE A=0 FOR LOAD X/Y=LOAD ADDRESS

            JSR CLOSE ;CLOSE FILE
}

This could be copied and pasted into multiple routines, but why? It is part of a loader so expanding the macro multiple times isn't harmful in this case, but the actual code becomes much easier to read.

+LDFILE file_a_addr, file_a_len, file_a_addr
+LDFILE file_b_addr, file_b_len, file_b_addr
+LDFILE file_c_addr, file_c_len, file_c_addr
+LDFILE file_d_addr, file_d_len, file_d_addr
+LDFILE file_e_addr, file_e_len, file_e_addr
+LDFILE file_f_addr, file_f_len, file_f_addr

Now, one must be careful. It is easy to get carried away with these and really bloat your code. Hence why the need for judgement and why there isn't a one size fits all approach. But I like looking at the latter example more that expands the macro six times rather than making six copies of the function and tweaking each to use custom parameters.

That doesn't mean I'm perfect and never copy and paste code. Sometimes you just want or need to get it done. Some will not like my use of macros.

[TomXP411]

Yeah, I tend to create a load of macros, as well. By the time I’m done, my programs are more macro than assembly. 

Essentially, what this means is I’m making up my own programming language. And I’m fine with that. 

[Ed Minchau]

I don't use macros at all; my editor doesn't have that feature. I can however copy and paste code. 

[Scott Robison]

On 10/3/2021 at 9:22 PM, Ed Minchau said:

I don't use macros at all; my editor doesn't have that feature. I can however copy and paste code. 

In this case, the macros are part of the assembler. Even notepad can use assembler macros. If the assembler supports, them, that is.

[TomXP411]

On 10/3/2021 at 8:22 PM, Ed Minchau said:

I don't use macros at all; my editor doesn't have that feature. I can however copy and paste code. 

Macros don’t come from the editor. The assembler does that. Technically, it’s part of the preprocessor, but most assemblers just integrate the preprocessor and the actual assembler.

So there’s usually a MACRO statement, which you follow with assembly code, like this:

name    .macro
        jsr print
        .null "Hello @1!";first parameter
        .endm

Source:  http://tass64.sourceforge.net/#macro 

Then you will invoke the macro, which replaces the macro call with the actual assembly:

#name “Tom”

Now you can use that anywhere in your code as a shorthand for a larger procedure. While this is obviously a trivial example, it’s very useful for doing repetitive tasks, like setting up KERNAL calls or 16-bit math. For example:

Add16 (adds two 16 bit numbers and stores the result in the specified address)
Print (takes the address of a null-terminated string and prints that to the screen using CHROUT)
Open and Close (for file I/O)

While Add16 seems trivial, it’s much easier to write something like Add16 Addr, 23 than to repeatedly write out the the several lines of code needed for a simple 16 bit add. 

Another reason macros are useful over copypasta is that you can fix a bugged macro much more easily than dozens or hundreds of places in a program where you repeat a piece of code. If it turns out you forgot to clear the Carry flag before an add, and you pasted that 130 times, you’d have to fix 130 instances of your error. But if you make an Add16 macro, you can do it in the macro, then just re-assemble the program.

 

[Ed Minchau]

On 10/4/2021 at 10:49 AM, TomXP411 said:

Macros don’t come from the editor. The assembler does that. Technically, it’s part of the preprocessor, but most assemblers just integrate the preprocessor and the actual assembler.

So there’s usually a MACRO statement, which you follow with assembly code, like this:

name    .macro
        jsr print
        .null "Hello @1!";first parameter
        .endm

Source:  http://tass64.sourceforge.net/#macro 

Then you will invoke the macro, which replaces the macro call with the actual assembly:

#name “Tom”

Now you can use that anywhere in your code as a shorthand for a larger procedure. While this is obviously a trivial example, it’s very useful for doing repetitive tasks, like setting up KERNAL calls or 16-bit math. For example:

Add16 (adds two 16 bit numbers and stores the result in the specified address)
Print (takes the address of a null-terminated string and prints that to the screen using CHROUT)
Open and Close (for file I/O)

While Add16 seems trivial, it’s much easier to write something like Add16 Addr, 23 than to repeatedly write out the the several lines of code needed for a simple 16 bit add. 

Another reason macros are useful over copypasta is that you can fix a bugged macro much more easily than dozens or hundreds of places in a program where you repeat a piece of code. If it turns out you forgot to clear the Carry flag before an add, and you pasted that 130 times, you’d have to fix 130 instances of your error. But if you make an Add16 macro, you can do it in the macro, then just re-assemble the program.

 

The problem for me is that I'm using the META/L editor, which is just a fancy monitor program with labels. There is no re-assembling the program, because all commands are converted into machine language as I type them. So, no macros.

[BruceMcF]

On 10/4/2021 at 6:49 PM, Ed Minchau said:

The problem for me is that I'm using the META/L editor, which is just a fancy monitor program with labels. There is no re-assembling the program, because all commands are converted into machine language as I type them. So, no macros.

Aha, a lot of people will assume you mean editing assembly language source (either a text editor or an assembler's IDE) when you refer to META/L as an "assembly editor".

The editing that is done is more directly editing the binary image, rather than editing assembly language source ... but OTOH it is not a classical binary editor, since it translated from assembly or character codes to binary.

If the clarification is that it's a fancy monitor with labels, that might be a better way to classify it ... the META/L monitor w/labels.

 

[TomXP411]

On 10/4/2021 at 3:49 PM, Ed Minchau said:

The problem for me is that I'm using the META/L editor, which is just a fancy monitor program with labels. There is no re-assembling the program, because all commands are converted into machine language as I type them. So, no macros.

Ah. I think there's an assembler that runs on the Commander.... if there's not, I think it's high time we build one. 

 

[Scott Robison]

On 10/5/2021 at 1:16 AM, TomXP411 said:

Ah. I think there's an assembler that runs on the Commander.... if there's not, I think it's high time we build one. 

 

I've started one several times but just don't have the free hours to put into it.

[Edmond D]

On 10/5/2021 at 12:16 AM, TomXP411 said:

Ah. I think there's an assembler that runs on the Commander.... if there's not, I think it's high time we build one. 

 

There is one hopefully going into the ROM (https://sites.google.com/view/x16asmenv/home), but the aim is to provide a simple tool. Macros not included. 

 

[TomXP411]

On 10/5/2021 at 9:14 AM, Scott Robison said:

I've started one several times but just don't have the free hours to put into it.

I have written an 8080 assembler in c#... so I know I can write a simple assembler in c. The issue is, as you said, I've only got so many hours a day. Right now, I'm learning a new musical instrument, starting to arrange songs for a brass band, and working 50 hours a week... so I don't have a huge amount of free time either.

Still, I might see how hard it is to do... maybe the solution is to port over something like Turbo Assembler, which already runs on the Commodore 64. 

 

[Ed Minchau]

On 10/4/2021 at 5:28 PM, BruceMcF said:

If the clarification is that it's a fancy monitor with labels, that might be a better way to classify it ... the META/L monitor w/labels.

 

It's in sort of a weird space in between monitor and editor. I'm writing the code directly, and can use the labels as part of the parameters,  but I can also insert and delete bytes as if I was making room in a text editor, and can copy or move code around.  The mnemonics are slightly different from the standard notation, too.

[Edmond D]

On 10/5/2021 at 12:59 PM, TomXP411 said:

I have written an 8080 assembler in c#... so I know I can write a simple assembler in c. The issue is, as you said, I've only got so many hours a day. Right now, I'm learning a new musical instrument, starting to arrange songs for a brass band, and working 50 hours a week... so I don't have a huge amount of free time either.

Still, I might see how hard it is to do... maybe the solution is to port over something like Turbo Assembler, which already runs on the Commodore 64. 

 

Perhaps a community-based group approach? I like many don't have a ton of free time, but there are many talented programmers here that perhaps could spend 2-3 hours a week on a group project. 

My other suggestion is to extend  the X16 Assembly Environment to support macros as an addition, rather than building a whole new tool or porting another design.

[TomXP411]

On 10/5/2021 at 1:56 PM, Edmond D said:

Perhaps a community-based group approach? I like many don't have a ton of free time, but there are many talented programmers here that perhaps could spend 2-3 hours a week on a group project. 

My other suggestion is to extend  the X16 Assembly Environment to support macros as an addition, rather than building a whole new tool or porting another design.

The X16 Assembly Environment isn't really an assembler. It's a replacement for the machine monitor. Just like you wouldn't write code with Supermon, you shouldn't be using the Assembly environment to write code: you might use it to enter already-written code, or to debug, but if you're writing a non-trivial piece of software, you need to be using a traditional assembler, not the X16AE.

 

[Scott Robison]

On 10/5/2021 at 1:59 PM, TomXP411 said:

I have written an 8080 assembler in c#... so I know I can write a simple assembler in c. The issue is, as you said, I've only got so many hours a day. Right now, I'm learning a new musical instrument, starting to arrange songs for a brass band, and working 50 hours a week... so I don't have a huge amount of free time either.  

I feel your pain. Except instead of music related stuff, it is learning about electronics, along with the 40+ hour work week and spending extra time helping with the Robots port to the 128. I'm glad to be doing it all! Just certain immutable laws of physics & biology preclude me doing much more at the moment.

[BruceMcF]

On 10/5/2021 at 4:03 PM, Ed Minchau said:

It's in sort of a weird space in between monitor and editor. I'm writing the code directly, and can use the labels as part of the parameters,  but I can also insert and delete bytes as if I was making room in a text editor, and can copy or move code around.  The mnemonics are slightly different from the standard notation, too.

I wouldn't consider being standard notation a critical issue ... heck, when the Z80 was created as a super-set of the 8080, Zilog used a quite different notation than the standard intel 8080 assembler notation.

Or "Assembly Binary Editor".

[Scott Robison]

On 10/5/2021 at 6:18 PM, BruceMcF said:

I wouldn't consider being standard notation a critical issue ... heck, when the Z80 was created as a super-set of the 8080, Zilog used a quite different notation than the standard intel 8080 assembler notation.

Or "Assembly Binary Editor".

I think Zilog went that way of necessity, not desire, as Intel threatened legal action or some such.

[TomXP411]

On 10/5/2021 at 5:41 PM, Scott Robison said:

I think Zilog went that way of necessity, not desire, as Intel threatened legal action or some such.

Intel claimed a Copyright on the mnemonics, which meant no one was allowed to use their names for their instructions. So even though the Z80 is 99% compatible with the 8080, Zilog had to make up their own names for the instructions. 

Eventually, the courts ruled that re-implementing instruction set mnemonics and software APIs are fair use - ie, you can't sue someone for using the same mnemonics as you.

In other words, Zilog didn't need to go to the trouble. 

 

[Scott Robison]

On 10/5/2021 at 8:12 PM, TomXP411 said:

Intel claimed a Copyright on the mnemonics, which meant no one was allowed to use their names for their instructions. So even though the Z80 is 99% compatible with the 8080, Zilog had to make up their own names for the instructions. 

Eventually, the courts ruled that re-implementing instruction set mnemonics and software APIs are fair use - ie, you can't sue someone for using the same mnemonics as you.

In other words, Zilog didn't need to go to the trouble. 

It probably cost them a lot less to design new mnemonics than the fight the court case in the short term. Many a company has gone bankrupt due to legal fees even when they were right in the end.

[BruceMcF]

On 10/5/2021 at 8:41 PM, Scott Robison said:

I think Zilog went that way of necessity, not desire, as Intel threatened legal action or some such.

I think I didn't make any claim that Zilog did it because just because they were really keen on the idea.

But the other example I had in mind is the classical FIG Forth 6502 assembler, with not only idiosyncratic mnemonics but also operand / instruction order.

Edited October 6, 2021 by BruceMcF

[Scott Robison]

On 10/5/2021 at 9:23 PM, BruceMcF said:

I think I didn't make any claim that Zilog did it because just because they were really keen on the idea.

But the other example I had in mind is the classical FIG Forth 6502 assembler, which not only idiosyncratic mnemonics but also operand / operand order.

Fair enough.

[Stefan]

New version 0.4.1 of X16 Edit published in the downloads section.

[desertfish]

@Stefan got the new launch-with-options working, however: how is the auto-indent supposed to work?  The editor never seems to auto indent for me....

[Stefan]

On 12/13/2021 at 12:15 AM, desertfish said:

@Stefan got the new launch-with-options working, however: how is the auto-indent supposed to work?  The editor never seems to auto indent for me....

Hi,

When a line break is inserted, it counts the number of leading spaces on the line. The same number of spaces is inserted at the beginning of next line.

I think that is the way most editors works, even Visual Studio Code that I use a lot.