Disassembly feature as a 3rd party extendable plug-in?

Wishlists for new functionality and features.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

You can revert the Int16 change if you want. I just noticed you defined IntX pointer types, so I thought for consistency I would also use Int16, there.
The other reason is that I can never remember the difference between ShortInt and SmallInt, especially since their meaning is reversed in C:
short int is at least 16 bit in C, but ShortInt usually 8 bit in Pascal (i.e. a signed byte). SmallInt is 16 bit in Pascal.

And since SmallInt is a fixed size type now in newer Delphi version, I thought it would be more clear to state it directly.

But it was just a "drive by"-change, nothing essential.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

I just wrote some code that would allow localizing the name, by special string variables like this:

{s:Disassembly(Param1, Param2, Param3, ...)}

First, I wanted to use the following syntax, but the %% will be reduced to just one % if the string is processed by Delphi's Format function first:
%%s:Disassembly(Param1, Param2, Param3, ...)%%

The curly bracket version goes through Format unchanged, but ideally I wanted to just use %, yet I can't think of a way that would be transparent to Delphi's Format.

In both cases, "Disassembly" is the name of a string variable, that will be replaced by the localized name in HxD.
So assuming you write Name={s:Disassembly(6809)} in your INI file (no gap before the open parens), it would show up in the datainspector grid like this:
"Disassembly (6809)" for English
"Disassemblat (6809)" for German

The plan is to add variables for all kind of common types, such as date/time, date&time, binary, and a bitness specifier (as in time_t (32 bit) for English, or time_t (32 Bit) for German).
That way you would get localized names for free, and would let the general translators handle this.

Ideally, you could translate all strings in plugins, but it would require satellite language files, and then some plugins would not end up translated, while others would. So I hope that offering a few generic strings will do.
GregC
Posts: 31
Joined: 08 Oct 2020 04:27

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by GregC »

Standardising on Int16 does make good sense. For completeness / consistency I've also updated the remaining SmallInt type references to be Int16 in the DasmConverter.pas source.

I've also added a source comment to explain the included RTLVersion directive.

Now committed to github as the following UPDATE:
  • Commit changes submitted by Maël Hörz, including:
  • - Add {$IF RTLVersion <= 27.0} directive block to support earlier Delphi version (XE6 and prior).
  • - Change to string type in place of AnsiString, and AnsiLowerCase in pace of LowerCase (for international character support).
  • - Change to Int16 type in place of SmallInt (for clarity and consistency of 2-byte Integer type usage).

ps. I just noted your lastest post above. Localized names for free in Plugins could be quite helpful.
Although for the Disassembly Plugin, a German language user could simply update the .ini directly to: Name=Disassemblat (6809)
Edit: But of course, translation for Free would be much better. :-)
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

That's good, I'll check out the code tomorrow, it's a bit late now.

Regarding the localized names, the reason is that when the plugin gets updated, you don't have to change the INI files again all the time, but also such that it adapts, no matter what your locale in HxD is, automatically.

Just like resourcestrings.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Ok, I implemented the string variables, and it seems they work fine.

The syntax is now like this:
{s:<StrVarName>(Param1, Param2, Param3, ...)}

Where ParamX is written as a string delimited by a double quote at the start and at the end. If the string should contain a double quote itself (i.e., " should be escaped), it can be written twice. That means "" becomes ".

For example:
{s:Disassembly("6502")}
will appear as:
Disassembly (6502)

Example with escaped double quotes:
{s:Disassembly("""6502""")}
will appear as:
Disassembly ("6502")

The list of available string variables (with their values given in English):
NameValue
Bitwidth%d bit
BinaryBinary (%s)
Date%s date
Time%s time
TimeDate%s time & date
DisassemblyDisassembly (%s)


The updated executables that contain the necessary code changes (for me it works, let me know if it works for you, too):

German:
https://mh-nexus.de/downloads/HxD25Deu.zip
English:
https://mh-nexus.de/downloads/HxD25Enu.zip

And the INI file that makes use of the string variable, can be found in the attachment. (Obviously, you could use the string variables directly in the plugin code, but since you put the names in the INI files, I adapted it there).

String variables are processed for TypeName and FriendlyTypeName values returned by the CreateConverter plugin function.

(I also tested your commits to GitHub and it compiles fine and without warnings or hints, thanks.)
Attachments
DasmDataInspectorPlugin.ini
(4.31 KiB) Downloaded 1077 times
GregC
Posts: 31
Joined: 08 Oct 2020 04:27

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by GregC »

Maël wrote: 05 Feb 2021 18:38 Ok, I implemented the string variables, and it seems they work fine.

The syntax is now like this:
{s:<StrVarName>(Param1, Param2, Param3, ...)}

Where ParamX is written as a string delimited by a double quote at the start and at the end. If the string should contain a double quote itself (i.e., " should be escaped), it can be written twice. That means "" becomes ".
Brilliant work!!! Yes, I just tested and all works for me (with both Enu and Deu versions). :)
Maël wrote: 05 Feb 2021 18:38 Obviously, you could use the string variables directly in the plugin code, but since you put the names in the INI files, I adapted it there.
Yes, this was also my immediate thought when I read through your implementation.

As you have already implement the "Disassembly(xxx)" as the hardwired name format in the DataInspector for your embedded x86 Disassembly, it would be logical for me to now remove the .ini "Name" string and also hardwire your new "Disassembly" string variable, simply passing the .ini DasmType (section name).
This is a simple one line code change, which I have just implemented and tested. :)

If you can just confirm that your string variable enhancement will be included in your pending v2.5.0.0 release, then I will commit this one line code change, along with the removal of the now redundant Name value from the .ini file.

ps. Do you have a target date for your v2.5.0.0 official release?
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Thanks :)
GregC wrote: 05 Feb 2021 20:00 If you can just confirm that your string variable enhancement will be included in your pending v2.5.0.0 release, then I will commit this one line code change, along with the removal of the now redundant Name value from the .ini file.

ps. Do you have a target date for your v2.5.0.0 official release?
Yes, it will be included in the 2.5 release. I just contacted the translators again, since it meant a few resourcestring changes.
I hope within a week I can make a release, even if not all translations are available.
GregC
Posts: 31
Joined: 08 Oct 2020 04:27

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by GregC »

Awesome. Changes now committed to github as the following UPDATE:
  • Change Disassembly type Name setting to now utilise the new DataInspectorPlugin string variable facility (enabling automatic localizing of "Disassembly").
  • Remove Name setting from .ini file (and update .ini comments), as Name now made redundant by above change.
Get it here: Disassembly Plugin on GitHub
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

4 translations are missing a couple strings, but I published HxD 2.5 now anyways, or I'll wait too long.

I mentioned you on the news feed of my website, and linked to your GitHub from there. I couldn't find your full name, so I addressed you as GregC/DigicoolThings. If you let me know your full name I can adapt it (if you want).

Edit: If you are on any rom hacking forums (or other places), you can make an announcement now, if you wish :)

Thanks again!
GregC
Posts: 31
Joined: 08 Oct 2020 04:27

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by GregC »

Hi Maël. HxD 2.5 now published! Awesome! Thank you for the mention. You're welcome to use my full name; Greg Clare

I do make a point of recommending HxD, whenever the topic is appropriate. Hopefully, my plugin will entice some more HxD users from the community of retro CPU users and also enthusiasts who enjoy hacking retro 8/16 bit gaming console (and computer) ROM code etc.

Perhaps someone might also want to contribute a Z80 Disassembly definition .csv file, or perhaps one for the HD6309, unless I get to it first. The Hitachi 6309 (which is an enhancement to the 6809), would probably be my next CPU of interest to add a Disassembly definition for.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Hi,

Quite a few people should like this, as I got requests for these CPU types before, but had no knowledge about them/no source code with a matching license. It should be a valuable extension :)

I adapted the credits to include your full name and linked to your GitHub from mine.

I was trying to think of a good way to summarize the CPUs you support. Is there a kind of category name, such as x86 or x86-64 for Intel/AMD/Cyrix processors?
GregC
Posts: 31
Joined: 08 Oct 2020 04:27

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by GregC »

Maël wrote: 12 Feb 2021 16:34 I was trying to think of a good way to summarize the CPUs you support. Is there a kind of category name, such as x86 or x86-64 for Intel/AMD/Cyrix processors?
x86 describes an instruction set architecture (ISA) family.

The CPU’s I’ve created Disassembly definition files for, are each their own ISA’s.

Perhaps the best way to categorise them is simply as being Retro / Early CPU architectures, from the 8 / 16 bit era.

Another way of categorising them is that I’m currently only supporting up to 2 Operands per instruction. Many 32 / 64 bit CPU architectures (including x86), can have 3 or more Operands for a single instruction.

You can find a useful ISA reference / comparison here: Comparison_of_instruction_set_architectures

Therefore, the current target for this Disassembly plugin is essentually: Retro 8 or 16-bit CPU architectures, that utilise no more than 2 Operands in any instruction.

More complex CPU architectures would likely require excessively large definition files, in order to uniquely identify each instruction variant. Even the 8/16-bit MC6809’s relatively comprehensive (for the time) “Indexed Addressing” mode requires 75 definitions per instruction to identify all of the possible Indexed Addressing mode unique instruction variants.

I’ve also currently limited a definition file to a reasonable maximum of 32,767 instruction definitions (each loaded definition is int16 indexed). Although this could have been extended, there would then be the question of performance impact on loading larger CPU definitions.
But, for reference, the 6809 uses 5,530 definitions, so 32,767 would seem still plenty of room for defining more complex CPU’s. :)
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Ok, judging mostly from Wikipedia, here is my list of observations:

MOS 6502 instruction set is similar to the one of Motorola 6800, but uses two 8 bit registers instead of one 16 bit register. Maybe a bit like Intel 8080 vs 8086? (8086 vs. 8088 were mostly architectural but not regarding the instruction set, as far as I know -- never used them though, just kept reading about them in assembler manuals.)

WDC 65C02 is an enhanced version of 6502.

(W65C02S is apparently the processor used in one of the Ben Eater videos I linked to earlier.)

WDC 65C816 or W65C816S is an enhanced version of the WDC 65C02.
65C816 and W65C816S seem to be different names for the same CPU?

Wikipedia and the datasheet of W65C02S https://eater.net/datasheets/w65c02s.pdf summarize these CPUs as 65xx:
https://en.wikipedia.org/wiki/MOS_Technology_65xx

Motorola MC6809 is an enhanced version of Motorola MC6800, also simply called Motorola 6809 and Motorola 6800.
Both summarized as 6800 family.

And finally here is a good summary of how all those CPUs are related:
https://en.wikipedia.org/wiki/Motorola_ ... 0_and_6502

So roughly you could say processors from the MOS/WDC 65xx and Motorola 6800 family.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Since both are inspired/based on Motorola 6800, the assembly would also be inspired by Motorola.

Now, to resume earlier comments/ideas about having more control over formatting (which would affect Intel assembly and Motorola 6800 and related assembly), I came up with three new options: configuring how hexadecimal numbers are marked/indicated, if they are lower or upper case, and if assembly instructions (and operators) are lower or upper case.

Regarding hexadecimal number formatting and naming of the styles:

https://en.wikipedia.org/wiki/Hexadecimal
Other assembly languages (6502, Motorola), Pascal, Delphi, some versions of BASIC (Commodore), GameMaker Language, Godot and Forth use $ as a prefix: $5A3.
This (and some other thoughts) leads us to four common styles to format hexadecimal numbers: Pascal/Motorola, C, Intel (with leading zero), Intel (without leading 0).

Examples of the four styles (order corresponding to the order of the style list above):
$FA1, 0xFA1, 0FA1h, FA1h

Additionally you can configure the casing of the letters in hexadecimal numbers, which gives us the lowercase option, as well:
$fa1, 0xfa1, 0fa1H, fa1H

Finally, the third option is to configure the casing of the instructions and operands, such that all can be lower or upper case, unless the casing is meaningful. But as far as I am aware, this it not the case for Intel assembly. How about Motorola 6800 and related assembly? Is the letter case of operands and instructions meaningful, or in other words, is 6800 and related assembly case sensitive?
Edit: at least for 68000, mnemonics seem to be written lower or upper case, depending on taste (still not clear if anything in disassembly is case sensitive).
https://simpledevcode.wordpress.com/201 ... ogramming/
http://mrjester.hapisan.com/04_MC68/


I am still working on making this clean and finished, and then will release those changes including the changes to the plugin interface to handle this.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Disassembly feature as a 3rd party extendable plug-in?

Post by Maël »

Not related directly, but I stumbled upon it while doing the above research:
https://en.wikipedia.org/wiki/Resident_monitor

https://www.avrfreaks.net/comment/20709 ... nt-2070941

Quite interesting as I was figuring out how AVR processors can be remote debugged.
Post Reply