Page 17 of 32
Re: Kowalski Simulator Updates
Posted: Sat Dec 25, 2021 3:49 am
by BigDumbDinosaur
The fix for the macro parameter mismatch causing the program to hang has been corrected.
The new version is v1.3.4.5 and can be downloaded from my website.
https://sbc.rictor.org/kowalski.html
Merry Christmas - happy holidays - Happy new year!!!
Daryl
Excellent!
Re: Kowalski Simulator Updates
Posted: Wed Dec 29, 2021 8:13 am
by BigDumbDinosaur
The fix for the macro parameter mismatch causing the program to hang has been corrected.
The new version is v1.3.4.5 and can be downloaded from my website.
https://sbc.rictor.org/kowalski.html
Merry Christmas - happy holidays - Happy new year!!!
Daryl
Unfortunately, I discovered macros declared with an ellipsis (variable number of parameters) no longer work. Assembly stops with the assembler complaining that the macro is being passed the wrong number of parameters. That shouldn't happen if an ellipsis is used in place of variables in the macro invocation.
Re: Kowalski Simulator Updates
Posted: Wed Dec 29, 2021 12:50 pm
by 8BIT
OK. This one may take a lot longer to fix.
Daryl
Re: Kowalski Simulator Updates
Posted: Fri Jan 07, 2022 4:57 am
by 8BIT
All,
I have fixed the Macro declaration with ellipsis error that I created with the previous patch.
The new version is 1.3.4.6 and can be downloaded from my website.
https://sbc.rictor.org/kowalski.html
2021 was a very busy year for me. 2022 looks like it will be even busier. I still intend to finish the 65816 support by adding the debugger (simulator), but I cannot provide an estimate of when it will be ready for first release.
Be safe and well!
Daryl
Re: Kowalski Simulator Updates
Posted: Fri Jan 07, 2022 5:18 am
by BigDumbDinosaur
I have fixed the Macro declaration with ellipsis error that I created with the previous patch.
The new version is 1.3.4.6 and can be downloaded from my website.
https://sbc.rictor.org/kowalski.html
Downloaded. I'll give it a spin.
Thanks!
Re: Kowalski Simulator Updates
Posted: Mon Jan 10, 2022 12:54 am
by BigDumbDinosaur
I have fixed the Macro declaration with ellipsis error that I created with the previous patch.
The new version is 1.3.4.6 and can be downloaded from my website.
https://sbc.rictor.org/kowalski.html
Downloaded. I'll give it a spin.
Thanks!
The .DS N and .RS N pseudo-ops are supposed to be synonyms for *=*+N, meaning they are supposed to advance the program counter N bytes without generating any object code. *=*+N is a common program idiom used to reserve dynamic storage space for runtime data. However, .DS N and .RS N are more convenient,¹ — less typing, especially if a lot of dynamic storage must be defined.
The anomaly is whereas *=*+N only advances the program counter N bytes, .DS N and .RS N do that and also generate null bytes through the area being reserved, which become part of the resulting program. It wouldn't be much of a problem if dynamic storage only took up a few bytes, but does become a potential problem if a lot of space is used.
For example, in my SCSI I/O routines, I define 512 and 1024 byte block buffers, e.g., .RS 512 and .RS 1024. That tacks several thousand useless nulls onto the total program size.
The assembler has the .DCB N,F pseudo-op, which advances the program counter N bytes and fills the intervening space with F. It appears the .DS and .RS pseudo-ops are behaving like .DCB, but with $00 hard-coded for F.
————————————————————
¹I have a macro named res (reserve) that does the *=*+N thing.
Re: Kowalski Simulator Updates
Posted: Fri Jan 14, 2022 12:54 pm
by 8BIT
I did some research and found that .RS and .DS act as you say. I have not altered that function since I started maintaining the source so it is acting as it was originally intended to act. I see no reason to change their behavior and worry that any change would impact others who use the assembler as it is written. If *=*+N does what you want it to do, then I recommend that you use that for your purpose.
Regards!
Daryl
Re: Kowalski Simulator Updates
Posted: Fri Jan 14, 2022 5:45 pm
by BigDumbDinosaur
I did some research and found that .RS and .DS act as you say. I have not altered that function since I started maintaining the source so it is acting as it was originally intended to act. I see no reason to change their behavior and worry that any change would impact others who use the assembler as it is written. If *=*+N does what you want it to do, then I recommend that you use that for your purpose.
It might be a good idea to edit the documentation for .DS and .RS to correctly describe their behavior.
Re: Kowalski Simulator Updates
Posted: Fri Jan 14, 2022 6:21 pm
by 8BIT
Will do. Thanks!
Re: Kowalski Simulator Updates
Posted: Fri Jan 14, 2022 6:29 pm
by BigDumbDinosaur
Do you have to recompile the source to do that?
Re: Kowalski Simulator Updates
Posted: Sat Jan 15, 2022 5:48 am
by 8BIT
The help can be compiled without doing the whole source, but its easier to just recompile the whole source - takes about 20 seconds at any rate, so not a problem.
Daryl
Re: Kowalski Simulator Updates
Posted: Sat Jan 15, 2022 5:44 pm
by 8BIT
The help can be compiled without doing the whole source, but its easier to just recompile the whole source - takes about 20 seconds at any rate, so not a problem.
Daryl
So, I forgot about the context selective help. To update that, it requires the source to be re-compiled.
I have updated the help documentation to better reflect the .DS & .RS operation. I also fixed a few typo's with the .ORG help. New version is 1.3.4.7 and can be found on my website.
https://sbc.rictor.org/kowalski.html
thanks!
Daryl
Re: Kowalski Simulator Updates
Posted: Sat Jan 15, 2022 7:02 pm
by BigDumbDinosaur
The help can be compiled without doing the whole source, but its easier to just recompile the whole source - takes about 20 seconds at any rate, so not a problem.
Daryl
So, I forgot about the context selective help. To update that, it requires the source to be re-compiled.
I have updated the help documentation to better reflect the .DS & .RS operation. I also fixed a few typo's with the .ORG help. New version is 1.3.4.7 and can be found on my website.
https://sbc.rictor.org/kowalski.html
thanks!
Daryl
Excellent. Thanks again for all your hard work.
Kowalski Simulator Updates: Macro Example
Posted: Thu Feb 10, 2022 9:35 pm
by BigDumbDinosaur
In the process of getting from point A to point B, I needed to write some macros that would reduce the amount of code that has to be entered to access functions in my SCSI library. Below is one of those macros, which illustrates some of the things that can be done with the Kowalski assembler's macro processor.
Something worth noting is the Kowalski assembler has separate dictionaries for macro names and labels/symbols (there is a difference, by the way, between a label and a symbol). The separate dictionaries feature makes it possible to name a macro after the function it invokes without any namespace collisions. You can see that in the below macro.
Code: Select all
;———————————————————————————————————————————————————————
;READ BLOCK(S) FROM SCSI DEVICE
;
;blkread *ID,*LBA,*NBLK,*BUF,<m1>,<m2>,<m3>,<m4>
;
; *ID — pointer to device bus ID
; *LBA — pointer to logical block address
; *NBLK — pointer to number of blocks to read
; *BUF — pointer to buffer
; <m1> — <m4> are addressing mode parameters:
;
; 'd' — Parameter is a direct page location containing a 32-bit pointer
; to an object, in standard little-endian format. It is assumed
; the direct page location is 4 contiguous bytes. An assembly-
; time error will occur if 'd' addressing is paired with any ad-
; dress greater than $FC.
;
; 'f' — Parameter is a 32-bit (“far”) address of an object. “Far” ad-
; dressing should not be used if the object is in the same bank
; as the program accessing it. “Near” addressing should be used
; instead.
;
; 'n' — Parameter is a 16-bit (“near”) address of an object assumed to
; be in the same bank as the program accessing it. If a 24- or
; 32-bit address is passed, the MSB or MSW will be ignored.
;
; 'r' — Parameter is ignored. The address of the object is passed in
; the index registers, with .X containing the LSW & .Y containing
; the MSW. The index registers will be set to 16 bits before be-
; ing pushed so as to satisfy the called function's stack frame
; requirements. It is recommended the parameter associated with
; register addressing be a literal zero so it is clear that it is
; not being used by the macro.
;
; Register addressing is limited to one parameter. If used more
; than once, an assembly-time error will occur.
;———————————————————————————————————————————————————————
;
blkread .macro ...
.rp =8 ;required number of parameters
.if @0 == .rp ;if required parameters were passed...
.np =.rp/2 ;number of address parameters
.ct .= .np ;loop counter
.xr .=0 ;register addressing flag
.rept .ct ;repeat following for each address parameter
.m .= {{@{.ct+.np}} | %00100000} ;down-case the addressing mode
.if .m == 'd' ;if direct page...
.if {@.ct} > $fc ;range-check address
.error ""+@0$+": 'DP' address out of range"
;
; ———————————————————————————————————————————————————————
; Note that assembly halts following an .error pseudo-op.
; ———————————————————————————————————————————————————————
;
.endif
pei {@.ct}+2 ;push MSW
pei {@.ct} ;push LSW
.else
.if .m == 'f' ;if “far” addressing...
.if {{@.ct} >> 16} > $ff ;range-check address
.error ""+@0$+": 'far' address out of range"
.endif
pea #{@.ct} >> 16 ;push MSW
pea #{@.ct} & $ffff ;push LSW
.else
.if .m == 'n' ;if “near” addressing...
.rept 2 ;execution bank is MSW
phk
.endr
per {@.ct} & $ffff ;push LSW
.else
.if .m == 'r' ;if register addressing...
.if .xr ;if already used...
.error ""+@0$+": 'r' addressing can only be used once"
.else
.xr .= 1 ;register addressing used
rep #%00010000 ;16-bit index
phy ;push MSW
phx ;push LSW
.endif
.else ;if an undefined addressing mode...
.error ""+@0$+": mode must be 'd', 'f', 'n' or 'r'"
.endif
.endif
.endif
.endif
.ct .= .ct-1 ;counter -1
.endr
.else
.error ""+@0$+": missing parameters"
.endif
.if .def(_SCSI_) ;if “_SCSI_” label defined...
jsl blkread ;use a “long” call
.else ;otherwise...
jsr blkread ;use a “short” call
.endif
.endm ;end of macro
Kowalski Simulator Updates: Say what?
Posted: Tue Feb 15, 2022 9:00 am
by BigDumbDinosaur
Okay, this is interesting.
I am writing a function that converts binary broken-down time to its ASCII equivalent, using a formatting mask. This is very similar to the date +%... options available in UNIX-like environments. My version is mostly POSIX-compliant, but that’s a discussion for another time.
Anyhow, the broken-down time is passed in a data table whose layout is almost identical to the tm structure of *NIX. Element offsets in the table are name tm_..., such as tm_wday for the day number of the week. As I was writing code, I mis-typed tm_wday as tm.wday. When I went to assemble my code, the assembler reported tm.wday as undefined. Once I had seen my typo, I was left a bit puzzled by this response.
Usually the assembler will complain about statement syntax when something in one of the fields is not to its liking, such as a misplaced comma or a label with a leading numeral. I would have expected tm.wday to trigger such an error. Since that didn't happen, it was apparent the assembler was treating tm.wday as a valid name. That led me to try assigning a value to tm.wday to see what would happen. The assembler accepted it:
The assembler documentation doesn't seem to indicate a dot is a valid character in a label or symbol. Evidently, it is.
This revelation means that long label/symbol names can be broken up into words using a dot, such as this.is.a.very.long.label, instead of the more common underscore, or something I heartily detest, use of upper-case letters at the start of each word, such as this: ThisIsAVeryLongLabel. Use of a dot instead of an underscore means one doesn't have shift to type an acceptable word separator.