Kowalski Simulator Updates

[barnacle]

I'm not a Kowalski user, but it strikes me that if there is a defined way to generate a 2-byte operand, you shouldn't do it unless that way is used: your example is a type error (unless you want to get into automatic type promotion, which I suspect you really don't.)

But you definitely don't want to use a truncated version - that way madness lies!

Neil

[fachat]

8BIT wrote:

Question for the group:

Assembling a 65816 file... should LDA #300 cause an error (parameter won't fit in a byte) or should I let it go and have it assemble 3 bytes (A9 2C 01). The intended way is to use LDA !#300, which forces a 2 byte operand. Having no error can lead to logic errors the programmer may miss.

thanks!
Daryl

In my understanding the assembler should handle this as an error. It is not specified to be 16 bit, so anything >255 should err.

xa65 has two modes of determining the operand size. You can either use LDA !value to force 16bit addressing (if zeropage it automatically uses zp addressing) or LDA #!value for a 16 bit immediate operand.

In 65816 mode, there are pseudo opcodes that tell the assembler how to handle index register or accumulator sizes:
.xs / .xl / .as / .al

André

[BigDumbDinosaur]

8BIT wrote:

Assembling a 65816 file... should LDA #300 cause an error (parameter won't fit in a byte) or should I let it go and have it assemble 3 bytes (A9 2C 01). The intended way is to use LDA !#300, which forces a 2 byte operand. Having no error can lead to logic errors the programmer may miss.

In Supermon 816, if LDA #300 is entered, the assembler will assemble a 16-bit immediate-mode operand.  That obviously will lead to a run-time error if the accumulator wasn’t previously set to 16 bits.  I stuck with that behavior as a matter of convenience, and with the assumption it’s a bare-metal environment, in which the programmer has to do all the thinking.  In the Kowalski assembler, I’d consider flagging that as an error, i.e., require the !# syntax if a 16-bit immediate-mode operand is wanted.  I do that as a matter of course in my programs to make it obvious that the 16-bit operand was intentional, even if the operand would evaluate to 16 bits.

[8BIT]

OK, three votes for an error message. Glad there was a consensus! I'll make that change to the assembler code and get an update posted in a few days.

thank you all for your input!
Daryl

[BigDumbDinosaur]

8BIT wrote:

OK, three votes for an error message. Glad there was a consensus! I'll make that change to the assembler code and get an update posted in a few days.

thank you all for your input!

And here I thought you were going to retire and start collecting your pension. 

[beethead]

8BIT wrote:

OK, three votes for an error message. Glad there was a consensus! I'll make that change to the assembler code and get an update posted in a few days.

thank you all for your input!
Daryl

Little late to the voting booth but I agree with throwing an error if the accumulator is set as 8bit mode (.as). Forcing a 16bit value with !# should bypass an error. Some assemblers also use ## or .w extension in the operator.

[8BIT]

BigDumbDinosaur wrote:

And here I thought you were going to retire and start collecting your pension. 

There seems to some delays in the "system", no retirement check yet.

[BigDumbDinosaur]

beethead wrote:

Little late to the voting booth but I agree with throwing an error if the accumulator is set as 8bit mode (.as).

Pedantic note: there is no “8bit mode.”  The 65C816 has two modes: emulation and native.  Accumulator operations are the same regardless of “width.”  All that changes is the number of bits being affected.

Quote:

Forcing a 16bit value with !# should bypass an error. Some assemblers also use ## or .w extension in the operator.

We had discussed use of ## at one time to indicate a 16-bit operand, but the idea was nixed as it is too easy to accidentally type that combination.  The !# combination is less likely to be accidentally entered, plus stands out more when reading source code.

[Yuri]

I have updated the github to include the 1.4.0.2 release:
https://github.com/Kelmar/kowalski/rele ... on_1.4.0.2

Edit:
Updated and rebuilt with Visual Studio 2022 and latest and greatest MFC version:
https://github.com/Kelmar/kowalski/rele ... 90.0_beta1

Ran the 65816 tests and they passed on this version.

[8BIT]

I have fixed the 16-bit immediate issue with the assembler. You now need to have the !# qualifier to assign 16-bit values. Program zip and source files are on my website. https://sbc.rictor.org/kowalski.html

thanks!
Daryl

[BigDumbDinosaur]

8BIT wrote:

I have fixed the 16-bit immediate issue with the assembler. You now need to have the !# qualifier to assign 16-bit values. Program zip and source files are on my website. https://sbc.rictor.org/kowalski.html

I will download and give ’er a spin.

[Yuri]

BigDumbDinosaur wrote:

As I’ve said before, I’ve yet to discern a pattern to the error.  All I know is it appears when trying to close the S&R dialog box after an S&R session has resulted in a change to the loaded source file.  It seems the error is more likely to occur after an extended editing session, which is why I think it’s tied somehow to the undo function—the undo stack will, of course, continuously grow as code is added to the source file being edited.  An S&R session that changes a lot of lines will rapidly expand the undo stack, which could be where the error originates.

Another possibility might be an obscure memory leak.  I’m not a Windows programmer, so I don’t know enough about that environment to offer any useful guidance.

Looks like it might be a combination of the two. After digging into this it would appear that the CrystalEdit controls Undo records are playing some games with their pointers based on behavior of what the OS may (or may not) be doing, ultimately trying to store single character in the pointer field itself, if that is the size of the undo.

I'm sure this saved some space in memory back in the day, but my experience has been that when you start trying to play games like that with your pointers, it ends badly. Let a pointer be a pointer, and not possibly something else relying on a "trick" that the OS might (or might not) continue to do; or that other programmers have to "remember" is being done in such a non conventional way which leads to bugs later on.

Also appears there's a potential memory leak with that code as well, where the undo record fails to release its memory if multiple calls are made to set it's text.

I'll get the changes made and create a diff file.

[Yuri]

Okay,

Undo system updated to remove potential memory bugs and clean up it's memory leak.

The patch can be had here:
https://github.com/Kelmar/kowalski/comm ... 9782.patch

If you prefer a more pretty looking diff (I recommend ignoring white space changes):
https://github.com/Kelmar/kowalski/comm ... nified&w=1

[8BIT]

great work Yuri. I'll try to get this updated on the old Visual Studio 8 version soon.

Were you able to come up with a repeatable way to cause the problem in the original version?

Daryl

[Yuri]

8BIT wrote:

great work Yuri. I'll try to get this updated on the old Visual Studio 8 version soon.

Were you able to come up with a repeatable way to cause the problem in the original version?

Daryl

Not quite, but it would seem that the undo buffer is limited to a max of about 1000 items in it. It will also reuse the structures as you add/remove from the undo list. When you do a find and replace it does push a fair number of items into that buffer, and then clears them out on the undo step. Given that it's playing games with the pointers and trying to make them do all sorts of things they shouldn't, I wouldn't be surprised to find out that some weird combo clobbers memory somewhere else thinking it's working with a string in the heap vs. a string in that array.

So I can't grantee that what I have will fix the issue BDD specifically reported; but I can at least say that it should be more correctly behaved, and isn't trying to use a pointer for what it wasn't intended for.
It also doesn't rely on a completely undocumented side effect of how the OS assigns pointers.

And I can at least say that it should be less likely to be leaking any memory as you use the undo system.