6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 9:49 pm

All times are UTC




Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 28  Next
Author Message
PostPosted: Sat Dec 25, 2021 3:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 8:13 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 12:50 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
OK. This one may take a lot longer to fix.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 07, 2022 4:57 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 07, 2022 5:18 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 10, 2022 12:54 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
BigDumbDinosaur wrote:
8BIT wrote:
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!

Things seem to be working. However, I did run across another anomaly.

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 14, 2022 12:54 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 14, 2022 5:45 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Fri Jan 14, 2022 6:28 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 14, 2022 6:21 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Will do. Thanks!

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 14, 2022 6:29 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
Will do. Thanks!

Do you have to recompile the source to do that?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 15, 2022 5:48 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 15, 2022 5:44 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
8BIT wrote:
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

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 15, 2022 7:02 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
8BIT wrote:
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 10, 2022 9:35 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
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:
;———————————————————————————————————————————————————————
;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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 15, 2022 9:00 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
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:

Code:
00988    000C              tm.wday  =tm_wday

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 28  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: