6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-11-29 10:50:28 +00:00
Code Issues Projects Releases Wiki Activity
4e70edc90c
6502bench/SourceGen/AsmGen/AsmTass64.cs

927 lines
39 KiB
C#
Raw Normal View History

Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
/*
* Copyright 2019 faddenSoft
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Diagnostics;
using System.IO;
using System.Text;
using Asm65;
using CommonUtil;
Move WPF code from SourceGenWPF to SourceGen
2019-07-20 20:28:10 +00:00
namespace SourceGen.AsmGen {
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
#region IGenerator
/// <summary>
/// Generate source code compatible with the 64tass assembler
/// (https://sourceforge.net/projects/tass64/).
///
/// The assembler is officially called "64tass", but it's sometimes written "tass64" because
/// in some cases you can't start an identifier with a number.
///
/// We need to deal with a couple of unusual aspects:
/// (1) The prefix for a local label is '_', which is generally a legal character. So
/// if somebody creates a label with a leading '_', and it's not actually local, we have
/// to "de-local" it somehow.
/// (2) By default, labels are handled in a case-insensitive fashion, which is extremely
/// rare for programming languages. Case sensitivity can be enabled with the "-C" flag.
/// Anybody who wants to assemble the generated code will need to be aware of this.
/// </summary>
public class GenTass64 : IGenerator {
private const string ASM_FILE_SUFFIX = "_64tass.S"; // must start with underscore
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
private const string ASCII_ENC_NAME = "sg_ascii";
private const string HIGH_ASCII_ENC_NAME = "sg_hiascii";
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
private const int MAX_OPERAND_LEN = 64;
// IGenerator
public DisasmProject Project { get; private set; }
// IGenerator
public Formatter SourceFormatter { get; private set; }
// IGenerator
public AppSettings Settings { get; private set; }
// IGenerator
public AssemblerQuirks Quirks { get; private set; }
// IGenerator
public LabelLocalizer Localizer { get { return mLocalizer; } }
/// <summary>
/// Working directory, i.e. where we write our output file(s).
/// </summary>
private string mWorkDirectory;
/// <summary>
/// If set, long labels get their own line.
/// </summary>
private bool mLongLabelNewLine;
/// <summary>
/// Output column widths.
/// </summary>
private int[] mColumnWidths;
/// <summary>
/// Base filename. Typically the project file name without the ".dis65" extension.
/// </summary>
private string mFileNameBase;
/// <summary>
/// StringBuilder to use when composing a line. Held here to reduce allocations.
/// </summary>
private StringBuilder mLineBuilder = new StringBuilder(100);
/// <summary>
/// Label localization helper.
/// </summary>
private LabelLocalizer mLocalizer;
/// <summary>
/// Stream to send the output to.
/// </summary>
private StreamWriter mOutStream;
/// <summary>
/// If we output a ".logical", we will need a ".here" eventually.
/// </summary>
private bool mNeedHereOp;
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
/// <summary>
/// What encoding are we currently set up for.
/// </summary>
private CharEncoding.Encoding mCurrentEncoding;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
/// <summary>
/// Holds detected version of configured assembler.
/// </summary>
private CommonUtil.Version mAsmVersion = CommonUtil.Version.NO_VERSION;
// Version we're coded against.
private static CommonUtil.Version V1_53 = new CommonUtil.Version(1, 53, 1515);
// Pseudo-op string constants.
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
private static PseudoOp.PseudoOpNames sDataOpNames =
new PseudoOp.PseudoOpNames(new Dictionary<string, string> {
{ "EquDirective", "=" },
Add VarDirective to PseudoOpNames Also, rearranged the pseudo-op app settings XAML to be a bit easier to maintain.
2019-08-29 19:14:47 +00:00
{ "VarDirective", ".var" },
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
{ "OrgDirective", ".logical" },
//RegWidthDirective // .as, .al, .xs, .xl
{ "DefineData1", ".byte" },
{ "DefineData2", ".word" },
{ "DefineData3", ".long" },
{ "DefineData4", ".dword" },
//DefineBigData2
//DefineBigData3
//DefineBigData4
{ "Fill", ".fill" },
Two changes to "dense hex" bulk data formatting (1) Added an option to limit the number of bytes per line. This is handy for things like bitmaps, where you might want to put (say) 3 or 8 bytes per line to reflect the structure. (2) Added an application setting that determines whether the screen listing shows Merlin/ACME dense hex (20edfd) or 64tass/cc65 hex bytes ($20,$ed,$fd). Made the setting part of the assembler-driven display definitions. Updated 64tass+cc65 to use ".byte" as their dense hex pseudo-op, and to use the updated formatter code. No changes to regression test output. (Changes were requested in issue #42.) Also, added a resize gripper to the bottom-right corner of the main window. (These seem to have generally fallen out of favor, but I like having it there.)
2019-12-11 01:41:00 +00:00
{ "Dense", ".byte" }, // not really dense, just comma-separated bytes
Add junk/align directives Sometimes there's a bunch of junk in the binary that isn't used for anything. Often it's there to make things line up at the start of a page boundary. This adds a ".junk" directive that tells the disassembler that it can safely disregard the contents of a region. If the region ends on a power-of-two boundary, an alignment value can be specified. The assembly source generators will output an alignment directive when possible, a .fill directive when appropriate, and a .dense directive when all else fails. Because we're required to regenerate the original data file, it's not always possible to avoid generating a hex dump.
2019-10-19 03:28:02 +00:00
//Junk
{ "Align", ".align" },
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
{ "StrGeneric", ".text" },
//StrReverse
{ "StrNullTerm", ".null" },
{ "StrLen8", ".ptext" },
//StrLen16
{ "StrDci", ".shift" }
});
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
private const string HERE_PSEUDO_OP = ".here";
// IGenerator
public void GetDefaultDisplayFormat(out PseudoOp.PseudoOpNames pseudoOps,
out Formatter.FormatConfig formatConfig) {
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
pseudoOps = sDataOpNames;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
formatConfig = new Formatter.FormatConfig();
SetFormatConfigValues(ref formatConfig);
}
// IGenerator
public void Configure(DisasmProject project, string workDirectory, string fileNameBase,
AssemblerVersion asmVersion, AppSettings settings) {
Debug.Assert(project != null);
Debug.Assert(!string.IsNullOrEmpty(workDirectory));
Debug.Assert(!string.IsNullOrEmpty(fileNameBase));
Project = project;
Quirks = new AssemblerQuirks();
Update 64tass handling of StackInt ops The operands for BRK and COP must be expressed as immediate mode constants, with a leading '#'.
2019-08-19 23:09:11 +00:00
Quirks.StackIntOperandIsImmediate = true;
Label rework, part 6 Correct handling of local variables. We now correctly uniquify them with regard to non-unique labels. Because local vars can effectively have global scope we mostly want to treat them as global, but they're uniquified relative to other globals very late in the process, so we can't just throw them in the symbol table and be done. Fortunately local variables exist in a separate namespace, so we just need to uniquify the variables relative to the post-localization symbol table. In other words, we take the symbol table, apply the label map, and rename any variable that clashes. This also fixes an older problem where we weren't masking the leading '_' on variable labels when generating 64tass output. The code list now makes non-unique labels obvious, but you can't tell the difference between unique global and unique local. What's more, the default type value in Edit Label is now adjusted to Global for unique locals that were auto-generated. To make it a bit easier to figure out what's what, the Info panel now has a "label type" line that reports the type. The 2023-non-unique-labels test had some additional tests added to exercise conflicts with local variables. The 2019-local-variables test output changed slightly because the de-duplicated variable naming convention was simplified.
2019-11-18 21:26:03 +00:00
Quirks.LeadingUnderscoreSpecial = true;
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
Quirks.Need24BitsForAbsPBR = true;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
mWorkDirectory = workDirectory;
mFileNameBase = fileNameBase;
Settings = settings;
mLongLabelNewLine = Settings.GetBool(AppSettings.SRCGEN_LONG_LABEL_NEW_LINE, false);
AssemblerConfig config = AssemblerConfig.GetConfig(settings,
AssemblerInfo.Id.Tass64);
mColumnWidths = (int[])config.ColumnWidths.Clone();
}
/// <summary>
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
/// Configures the assembler-specific format items. May be called without a Project.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
/// </summary>
private void SetFormatConfigValues(ref Formatter.FormatConfig config) {
// Must be lower case when --case-sensitive is used.
config.mUpperOpcodes = false;
config.mUpperPseudoOpcodes = false;
config.mUpperOperandA = false;
config.mUpperOperandS = false;
config.mUpperOperandXY = false;
config.mBankSelectBackQuote = true;
First pass at ACME support I managed to work around most of the quirks, but there's still an issue with 65816 code. Also, enabled word wrapping in the AsmGen text boxes.
2019-08-04 03:54:07 +00:00
config.mForceDirectOpcodeSuffix = string.Empty;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
config.mForceAbsOpcodeSuffix = string.Empty;
config.mForceLongOpcodeSuffix = string.Empty;
config.mForceDirectOperandPrefix = string.Empty;
config.mForceAbsOperandPrefix = "@w"; // word
config.mForceLongOperandPrefix = "@l"; // long
config.mEndOfLineCommentDelimiter = ";";
config.mFullLineCommentDelimiterBase = ";";
config.mBoxLineCommentDelimiter = ";";
Label rework, part 2 Continue development of non-unique labels. The actual labels are still unique, because we append a uniquifier tag, which gets added and removed behind the scenes. We're currently using the six-digit hex file offset because this is only used for internal address symbols. The label editor and most of the formatters have been updated. We can't yet assemble code that includes non-unique labels, but older stuff hasn't been broken. This removes the "disable label localization" property, since that's fundamentally incompatible with what we're doing, and adds a non- unique label prefix setting so you can put '@' or ':' in front of your should-be-local labels. Also, fixed a field name typo.
2019-11-13 01:24:41 +00:00
config.mNonUniqueLabelPrefix = ""; // should be '_', but that's a valid label char
Two changes to "dense hex" bulk data formatting (1) Added an option to limit the number of bytes per line. This is handy for things like bitmaps, where you might want to put (say) 3 or 8 bytes per line to reflect the structure. (2) Added an application setting that determines whether the screen listing shows Merlin/ACME dense hex (20edfd) or 64tass/cc65 hex bytes ($20,$ed,$fd). Made the setting part of the assembler-driven display definitions. Updated 64tass+cc65 to use ".byte" as their dense hex pseudo-op, and to use the updated formatter code. No changes to regression test output. (Changes were requested in issue #42.) Also, added a resize gripper to the bottom-right corner of the main window. (These seem to have generally fallen out of favor, but I like having it there.)
2019-12-11 01:41:00 +00:00
config.mCommaSeparatedDense = true;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
config.mExpressionMode = Formatter.FormatConfig.ExpressionMode.Common;
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
}
// IGenerator
public List<string> GenerateSource(BackgroundWorker worker) {
List<string> pathNames = new List<string>(1);
string fileName = mFileNameBase + ASM_FILE_SUFFIX;
string pathName = Path.Combine(mWorkDirectory, fileName);
pathNames.Add(pathName);
Formatter.FormatConfig config = new Formatter.FormatConfig();
GenCommon.ConfigureFormatterFromSettings(Settings, ref config);
SetFormatConfigValues(ref config);
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
// Configure delimiters for single-character operands.
Formatter.DelimiterSet charDelimSet = new Formatter.DelimiterSet();
charDelimSet.Set(CharEncoding.Encoding.C64Petscii, Formatter.SINGLE_QUOTE_DELIM);
charDelimSet.Set(CharEncoding.Encoding.C64ScreenCode, Formatter.SINGLE_QUOTE_DELIM);
charDelimSet.Set(CharEncoding.Encoding.Ascii, Formatter.SINGLE_QUOTE_DELIM);
charDelimSet.Set(CharEncoding.Encoding.HighAscii,
new Formatter.DelimiterDef(string.Empty, '\'', '\'', " | $80"));
config.mCharDelimiters = charDelimSet;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
SourceFormatter = new Formatter(config);
string msg = string.Format(Res.Strings.PROGRESS_GENERATING_FMT, pathName);
worker.ReportProgress(0, msg);
mLocalizer = new LabelLocalizer(Project);
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
mLocalizer.LocalPrefix = "_";
Label rework, part 5 Implemented assembly source generation of non-unique local labels. The new 2023-non-unique-labels test exercises various edge cases (though we're still missing local variable interaction). The format of uniquified labels changed slightly, so the expected output of 2012-label-localizer needed to be updated. This changes the "no opcode mnemonics" and "mask leading underscores" functions into integrated parts of the label localization process.
2019-11-18 00:05:51 +00:00
mLocalizer.QuirkNoOpcodeMnemonics = true;
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
mLocalizer.Analyze();
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// Use UTF-8 encoding, without a byte-order mark.
using (StreamWriter sw = new StreamWriter(pathName, false, new UTF8Encoding(false))) {
mOutStream = sw;
if (Settings.GetBool(AppSettings.SRCGEN_ADD_IDENT_COMMENT, false)) {
OutputLine(SourceFormatter.FullLineCommentDelimiter +
string.Format(Res.Strings.GENERATED_FOR_VERSION_FMT,
"64tass", V1_53, AsmTass64.OPTIONS));
}
GenCommon.Generate(this, sw, worker);
if (mNeedHereOp) {
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(HERE_PSEUDO_OP),
string.Empty, string.Empty);
}
}
mOutStream = null;
return pathNames;
}
// IGenerator
public void OutputAsmConfig() {
CpuDef cpuDef = Project.CpuDef;
string cpuStr;
if (cpuDef.Type == CpuDef.CpuType.Cpu65816) {
cpuStr = "65816";
} else if (cpuDef.Type == CpuDef.CpuType.Cpu65C02) {
cpuStr = "65c02";
} else if (cpuDef.Type == CpuDef.CpuType.Cpu6502 && cpuDef.HasUndocumented) {
cpuStr = "6502i";
} else {
cpuStr = "6502";
}
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(".cpu"),
'\"' + cpuStr + '\"', string.Empty);
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
// C64 PETSCII and C64 screen codes are built in. Define ASCII if we also
// need that.
mCurrentEncoding = CharEncoding.Encoding.C64Petscii;
CheckAsciiFormats(out bool hasAscii, out bool hasHighAscii);
if (hasHighAscii) {
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", '"' + HIGH_ASCII_ENC_NAME + '"', string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
OutputLine(string.Empty, ".cdef", "$20,$7e,$a0", string.Empty);
mCurrentEncoding = CharEncoding.Encoding.HighAscii;
}
if (hasAscii) {
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", '"' + ASCII_ENC_NAME + '"', string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
OutputLine(string.Empty, ".cdef", "$20,$7e,$20", string.Empty);
mCurrentEncoding = CharEncoding.Encoding.Ascii;
}
}
private void CheckAsciiFormats(out bool hasAscii, out bool hasHighAscii) {
int offset = 0;
hasAscii = hasHighAscii = false;
while (offset < Project.FileData.Length) {
Anattrib attr = Project.GetAnattrib(offset);
FormatDescriptor dfd = attr.DataDescriptor;
if (dfd != null) {
if (dfd.FormatSubType == FormatDescriptor.SubType.Ascii) {
Debug.Assert(dfd.IsNumeric || dfd.IsString);
hasAscii = true;
} else if (dfd.FormatSubType == FormatDescriptor.SubType.HighAscii) {
hasHighAscii = true;
}
}
if (hasAscii && hasHighAscii) {
return;
}
Correctly handle embedded instruction edge case This began with a change to support "BRK <operand>" in cc65. The assembler only supports this for 65816 projects, so we detect that and enable it when available. While fiddling with some test code an assertion fired. This revealed a minor issue in the code analyzer: when overwriting inline data with instructions, we weren't resetting the format descriptor. The code that exercises it, which requires two-byte BRKs and an inline BRK handler in an extension script, has been added to test 2022-extension-scripts. The new regression test revealed a flaw in the 64tass code generator's character encoding scanner that caused it to hang. Fixed.
2019-10-19 23:23:42 +00:00
if (attr.IsInstructionStart) {
// look for embedded instructions, which might have formatted char data
int len;
for (len = 1; len < attr.Length; len++) {
if (Project.GetAnattrib(offset + len).IsInstructionStart) {
break;
}
}
offset += len;
} else {
// data items
offset += attr.Length;
}
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
}
}
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// IGenerator
public string ModifyOpcode(int offset, OpDef op) {
if (op.IsUndocumented) {
if (Project.CpuDef.Type == CpuDef.CpuType.Cpu65C02) {
// none of the "LDD" stuff is handled
return null;
}
if ((op.Mnemonic == OpName.ANC && op.Opcode != 0x0b) ||
(op.Mnemonic == OpName.JAM && op.Opcode != 0x02)) {
// There are multiple opcodes that match the mnemonic. Output the
// mnemonic for the first one and hex for the rest.
return null;
} else if (op.Mnemonic == OpName.NOP || op.Mnemonic == OpName.DOP ||
op.Mnemonic == OpName.TOP) {
// the various undocumented no-ops aren't handled
return null;
} else if (op.Mnemonic == OpName.SBC) {
// this is the alternate reference to SBC
return null;
} else if (op == OpDef.OpSHA_DPIndIndexY) {
// not recognized ($93)
return null;
}
}
Update 64tass handling of StackInt ops The operands for BRK and COP must be expressed as immediate mode constants, with a leading '#'.
2019-08-19 23:09:11 +00:00
if (op == OpDef.OpWDM_WDM) {
// 64tass v1.54 doesn't like this to have an operand. Output as hex.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
return null;
}
return string.Empty; // indicate original is fine
}
Work around two assembler issues Most assemblers end local label scope when a global label is encountered. cc65 takes this one step further by ending local label scope when constants or variables are defined. So, if we have a variable table with a nonzero number of entries, we want to create a fake global label at that point to end the scope. Merlin 32 won't let you write " LDA #',' ". For some reason the comma causes an error. IGenerator now has a "tweak operand format" interface that lets us fix that.
2019-09-20 21:05:17 +00:00
// IGenerator
public FormatDescriptor ModifyInstructionOperandFormat(int offset, FormatDescriptor dfd,
int operand) {
return dfd;
}
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
// IGenerator
public void UpdateCharacterEncoding(FormatDescriptor dfd) {
Eliminate duplicate function
2019-08-21 22:29:00 +00:00
CharEncoding.Encoding newEnc = PseudoOp.SubTypeToEnc(dfd.FormatSubType);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
if (newEnc == CharEncoding.Encoding.Unknown) {
// probably not a character operand
return;
}
if (newEnc != mCurrentEncoding) {
switch (newEnc) {
case CharEncoding.Encoding.Ascii:
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", '"' + ASCII_ENC_NAME + '"', string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
break;
case CharEncoding.Encoding.HighAscii:
// If this is a numeric operand (not string), and we're currently in
// ASCII mode, the "| $80" in the delimiter will handle this without
// the need for a .enc. Much less clutter for sources that have plain
// ASCII strings but test high ASCII constants.
if (mCurrentEncoding == CharEncoding.Encoding.Ascii && !dfd.IsString) {
newEnc = mCurrentEncoding;
} else {
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", '"' + HIGH_ASCII_ENC_NAME + '"',
string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
}
break;
case CharEncoding.Encoding.C64Petscii:
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", "\"none\"", string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
break;
case CharEncoding.Encoding.C64ScreenCode:
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
OutputLine(string.Empty, ".enc", "\"screen\"", string.Empty);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
break;
default:
Debug.Assert(false);
break;
}
mCurrentEncoding = newEnc;
}
}
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// IGenerator
public void GenerateShortSequence(int offset, int length, out string opcode,
out string operand) {
Debug.Assert(length >= 1 && length <= 4);
// Use a comma-separated list of individual hex bytes.
opcode = sDataOpNames.DefineData1;
StringBuilder sb = new StringBuilder(length * 4);
for (int i = 0; i < length; i++) {
if (i != 0) {
sb.Append(',');
}
sb.Append(SourceFormatter.FormatHexValue(Project.FileData[offset + i], 2));
}
operand = sb.ToString();
}
// IGenerator
public void OutputDataOp(int offset) {
Formatter formatter = SourceFormatter;
byte[] data = Project.FileData;
Anattrib attr = Project.GetAnattrib(offset);
string labelStr = string.Empty;
if (attr.Symbol != null) {
labelStr = mLocalizer.ConvLabel(attr.Symbol.Label);
}
string commentStr = SourceFormatter.FormatEolComment(Project.Comments[offset]);
string opcodeStr, operandStr;
FormatDescriptor dfd = attr.DataDescriptor;
Debug.Assert(dfd != null);
int length = dfd.Length;
Debug.Assert(length > 0);
bool multiLine = false;
switch (dfd.FormatType) {
case FormatDescriptor.Type.Default:
if (length != 1) {
Debug.Assert(false);
length = 1;
}
opcodeStr = sDataOpNames.DefineData1;
int operand = RawData.GetWord(data, offset, length, false);
operandStr = formatter.FormatHexValue(operand, length * 2);
break;
case FormatDescriptor.Type.NumericLE:
opcodeStr = sDataOpNames.GetDefineData(length);
operand = RawData.GetWord(data, offset, length, false);
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
UpdateCharacterEncoding(dfd);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
operandStr = PseudoOp.FormatNumericOperand(formatter, Project.SymbolTable,
mLocalizer.LabelMap, dfd, operand, length,
Minor tweaks - Renamed "strip label prefix/suffix" to "omit label prefix/suffix". - Changed a Merlin operand workaround so it doesn't apply to code that is explicitly not in bank zero. - Changed {addr}/{const} annotations on project/platform symbol equates so they line up a little better on screen and in exported sources.
2019-11-16 00:15:31 +00:00
PseudoOp.FormatNumericOpFlags.OmitLabelPrefixSuffix);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
break;
case FormatDescriptor.Type.NumericBE:
opcodeStr = sDataOpNames.GetDefineBigData(length);
Various improvements The PseudoOpNames class is increasingly being used in situations where mutability is undesirable. This change makes instances immutable, eliminating the Copy() method and adding a constructor that takes a Dictionary. The serialization code now operates on a Dictionary instead of the class properties, but the JSON encoding is identical, so this doesn't invalidate app settings file data. Added an equality test to PseudoOpNames. In LineListGen, don't reset the line list if the names haven't actually changed. Use a table lookup for C64 character conversions. I figure that should be faster than multiple conditionals on a modern x64 system. Fixed a 64tass generator issue where we tried to query project properties in a call that might not have a project available (specifically, getting FormatConfig values out of the generator for use in the "quick set" buttons for Display Format). Fixed a regression test harness issue where, if the assembler reported success but didn't actually generate output, an exception would be thrown that halted the tests. Increased the width of text entry fields on the Pseudo-Op tab of app settings. The previous 8-character limit wasn't wide enough to hold ACME's "!pseudopc". Also, use TrimEnd() to remove trailing spaces (leading spaces are still allowed). In the last couple of months, Win10 started stalling for a fraction of a second when executing assemblers. It doesn't do this every time; mostly it happens if it has been a while since the assembler was run. My guess is this has to do with changes to the built-in malware scanner. Whatever the case, we now change the mouse pointer to a wait cursor while updating the assembler version cache.
2019-08-17 18:14:05 +00:00
if ((string.IsNullOrEmpty(opcodeStr))) {
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// Nothing defined, output as comma-separated single-byte values.
GenerateShortSequence(offset, length, out opcodeStr, out operandStr);
} else {
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
UpdateCharacterEncoding(dfd);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
operand = RawData.GetWord(data, offset, length, true);
operandStr = PseudoOp.FormatNumericOperand(formatter, Project.SymbolTable,
mLocalizer.LabelMap, dfd, operand, length,
Minor tweaks - Renamed "strip label prefix/suffix" to "omit label prefix/suffix". - Changed a Merlin operand workaround so it doesn't apply to code that is explicitly not in bank zero. - Changed {addr}/{const} annotations on project/platform symbol equates so they line up a little better on screen and in exported sources.
2019-11-16 00:15:31 +00:00
PseudoOp.FormatNumericOpFlags.OmitLabelPrefixSuffix);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
}
break;
case FormatDescriptor.Type.Fill:
opcodeStr = sDataOpNames.Fill;
operandStr = length + "," + formatter.FormatHexValue(data[offset], 2);
break;
case FormatDescriptor.Type.Dense:
multiLine = true;
opcodeStr = operandStr = null;
OutputDenseHex(offset, length, labelStr, commentStr);
break;
Add junk/align directives Sometimes there's a bunch of junk in the binary that isn't used for anything. Often it's there to make things line up at the start of a page boundary. This adds a ".junk" directive that tells the disassembler that it can safely disregard the contents of a region. If the region ends on a power-of-two boundary, an alignment value can be specified. The assembly source generators will output an alignment directive when possible, a .fill directive when appropriate, and a .dense directive when all else fails. Because we're required to regenerate the original data file, it's not always possible to avoid generating a hex dump.
2019-10-19 03:28:02 +00:00
case FormatDescriptor.Type.Junk:
int fillVal = Helper.CheckRangeHoldsSingleValue(data, offset, length);
if (fillVal >= 0 && GenCommon.CheckJunkAlign(offset, dfd, Project.AddrMap)) {
// .align <expression>[, <fill>]
opcodeStr = sDataOpNames.Align;
int alignVal = 1 << FormatDescriptor.AlignmentToPower(dfd.FormatSubType);
operandStr = alignVal.ToString() +
"," + formatter.FormatHexValue(fillVal, 2);
} else if (fillVal >= 0) {
// treat same as Fill
opcodeStr = sDataOpNames.Fill;
operandStr = length + "," + formatter.FormatHexValue(fillVal, 2);
} else {
// treat same as Dense
multiLine = true;
opcodeStr = operandStr = null;
OutputDenseHex(offset, length, labelStr, commentStr);
}
break;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
case FormatDescriptor.Type.StringGeneric:
case FormatDescriptor.Type.StringReverse:
case FormatDescriptor.Type.StringNullTerm:
case FormatDescriptor.Type.StringL8:
case FormatDescriptor.Type.StringL16:
case FormatDescriptor.Type.StringDci:
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
multiLine = true;
opcodeStr = operandStr = null;
OutputString(offset, labelStr, commentStr);
break;
default:
opcodeStr = "???";
operandStr = "***";
break;
}
if (!multiLine) {
opcodeStr = formatter.FormatPseudoOp(opcodeStr);
OutputLine(labelStr, opcodeStr, operandStr, commentStr);
}
}
private void OutputDenseHex(int offset, int length, string labelStr, string commentStr) {
Formatter formatter = SourceFormatter;
byte[] data = Project.FileData;
Two changes to "dense hex" bulk data formatting (1) Added an option to limit the number of bytes per line. This is handy for things like bitmaps, where you might want to put (say) 3 or 8 bytes per line to reflect the structure. (2) Added an application setting that determines whether the screen listing shows Merlin/ACME dense hex (20edfd) or 64tass/cc65 hex bytes ($20,$ed,$fd). Made the setting part of the assembler-driven display definitions. Updated 64tass+cc65 to use ".byte" as their dense hex pseudo-op, and to use the updated formatter code. No changes to regression test output. (Changes were requested in issue #42.) Also, added a resize gripper to the bottom-right corner of the main window. (These seem to have generally fallen out of favor, but I like having it there.)
2019-12-11 01:41:00 +00:00
int maxPerLine = MAX_OPERAND_LEN / formatter.CharsPerDenseByte;
string opcodeStr = formatter.FormatPseudoOp(sDataOpNames.Dense);
for (int i = 0; i < length; i += maxPerLine) {
int subLen = length - i;
if (subLen > maxPerLine) {
subLen = maxPerLine;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
}
Two changes to "dense hex" bulk data formatting (1) Added an option to limit the number of bytes per line. This is handy for things like bitmaps, where you might want to put (say) 3 or 8 bytes per line to reflect the structure. (2) Added an application setting that determines whether the screen listing shows Merlin/ACME dense hex (20edfd) or 64tass/cc65 hex bytes ($20,$ed,$fd). Made the setting part of the assembler-driven display definitions. Updated 64tass+cc65 to use ".byte" as their dense hex pseudo-op, and to use the updated formatter code. No changes to regression test output. (Changes were requested in issue #42.) Also, added a resize gripper to the bottom-right corner of the main window. (These seem to have generally fallen out of favor, but I like having it there.)
2019-12-11 01:41:00 +00:00
string operandStr = formatter.FormatDenseHex(data, offset + i, subLen);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Two changes to "dense hex" bulk data formatting (1) Added an option to limit the number of bytes per line. This is handy for things like bitmaps, where you might want to put (say) 3 or 8 bytes per line to reflect the structure. (2) Added an application setting that determines whether the screen listing shows Merlin/ACME dense hex (20edfd) or 64tass/cc65 hex bytes ($20,$ed,$fd). Made the setting part of the assembler-driven display definitions. Updated 64tass+cc65 to use ".byte" as their dense hex pseudo-op, and to use the updated formatter code. No changes to regression test output. (Changes were requested in issue #42.) Also, added a resize gripper to the bottom-right corner of the main window. (These seem to have generally fallen out of favor, but I like having it there.)
2019-12-11 01:41:00 +00:00
OutputLine(labelStr, opcodeStr, operandStr, commentStr);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
labelStr = commentStr = string.Empty;
}
}
/// <summary>
/// Outputs formatted data in an unformatted way, because the code generator couldn't
/// figure out how to do something better.
/// </summary>
private void OutputNoJoy(int offset, int length, string labelStr, string commentStr) {
byte[] data = Project.FileData;
Debug.Assert(length > 0);
Debug.Assert(offset >= 0 && offset < data.Length);
bool singleValue = true;
byte val = data[offset];
for (int i = 1; i < length; i++) {
if (data[offset + i] != val) {
singleValue = false;
break;
}
}
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
if (singleValue && length > 1) {
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
string opcodeStr = SourceFormatter.FormatPseudoOp(sDataOpNames.Fill);
string operandStr = length + "," + SourceFormatter.FormatHexValue(val, 2);
OutputLine(labelStr, opcodeStr, operandStr, commentStr);
} else {
OutputDenseHex(offset, length, labelStr, commentStr);
}
}
// IGenerator
public void OutputEquDirective(string name, string valueStr, string comment) {
OutputLine(name, SourceFormatter.FormatPseudoOp(sDataOpNames.EquDirective),
valueStr, SourceFormatter.FormatEolComment(comment));
}
Add VarDirective to PseudoOpNames Also, rearranged the pseudo-op app settings XAML to be a bit easier to maintain.
2019-08-29 19:14:47 +00:00
// IGenerator
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
public void OutputLocalVariableTable(int offset, List<DefSymbol> newDefs,
LocalVariableTable allDefs) {
foreach (DefSymbol defSym in newDefs) {
string valueStr = PseudoOp.FormatNumericOperand(SourceFormatter,
Project.SymbolTable, null, defSym.DataDescriptor, defSym.Value, 1,
Minor tweaks - Renamed "strip label prefix/suffix" to "omit label prefix/suffix". - Changed a Merlin operand workaround so it doesn't apply to code that is explicitly not in bank zero. - Changed {addr}/{const} annotations on project/platform symbol equates so they line up a little better on screen and in exported sources.
2019-11-16 00:15:31 +00:00
PseudoOp.FormatNumericOpFlags.OmitLabelPrefixSuffix);
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
OutputLine(SourceFormatter.FormatVariableLabel(defSym.Label),
SourceFormatter.FormatPseudoOp(sDataOpNames.VarDirective),
valueStr, SourceFormatter.FormatEolComment(defSym.Comment));
}
Add VarDirective to PseudoOpNames Also, rearranged the pseudo-op app settings XAML to be a bit easier to maintain.
2019-08-29 19:14:47 +00:00
}
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// IGenerator
public void OutputOrgDirective(int offset, int address) {
// 64tass separates the "compile offset", which determines where the output fits
// into the generated binary, and "program counter", which determines the code
// the assembler generates. Since we need to explicitly specify every byte in
// the output file, the compile offset isn't very useful. We want to set it once
// before the first line of code, then leave it alone.
//
// Any subsequent ORG changes are made to the program counter, and take the form
// of a pair of ops (.logical <addr> to open, .here to end). Omitting the .here
// causes an error.
if (offset == 0) {
// Set the "compile offset" to the initial address.
OutputLine("*", "=", SourceFormatter.FormatHexValue(Project.AddrMap.Get(0), 4),
string.Empty);
} else {
if (mNeedHereOp) {
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(HERE_PSEUDO_OP),
string.Empty, string.Empty);
}
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(sDataOpNames.OrgDirective),
SourceFormatter.FormatHexValue(address, 4), string.Empty);
mNeedHereOp = true;
}
}
// IGenerator
public void OutputRegWidthDirective(int offset, int prevM, int prevX, int newM, int newX) {
if (prevM != newM) {
string mop = (newM == 0) ? ".al" : ".as";
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(mop),
string.Empty, string.Empty);
}
if (prevX != newX) {
string xop = (newX == 0) ? ".xl" : ".xs";
OutputLine(string.Empty, SourceFormatter.FormatPseudoOp(xop),
string.Empty, string.Empty);
}
}
// IGenerator
public void OutputLine(string fullLine) {
mOutStream.WriteLine(fullLine);
}
// IGenerator
public void OutputLine(string label, string opcode, string operand, string comment) {
Local variables mostly work Variables are now handled properly end-to-end, except for label uniquification. So cc65 and ACME can't yet handle a file that redefines a local variable. This required a bunch of plumbing, but I think it came out okay.
2019-08-31 01:33:05 +00:00
// Break the line if the label is long and it's not a .EQ/.VAR directive.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
if (!string.IsNullOrEmpty(label) &&
!string.Equals(opcode, sDataOpNames.EquDirective,
Local variables mostly work Variables are now handled properly end-to-end, except for label uniquification. So cc65 and ACME can't yet handle a file that redefines a local variable. This required a bunch of plumbing, but I think it came out okay.
2019-08-31 01:33:05 +00:00
StringComparison.InvariantCultureIgnoreCase) &&
!string.Equals(opcode, sDataOpNames.VarDirective,
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
StringComparison.InvariantCultureIgnoreCase)) {
if (mLongLabelNewLine && label.Length >= mColumnWidths[0]) {
mOutStream.WriteLine(label);
label = string.Empty;
}
}
mLineBuilder.Clear();
Change the way the "add padded string" functions work The functions started by trying to pad a column out to a width, then changed to pad things to a certain length. What they really should be doing is padding the start of an entry to a specified column. This is much more natural and avoids a trim operation. The only change to the output is to ORG statements from the HTML exporter, which are now formatted correctly.
2019-09-18 05:02:05 +00:00
TextUtil.AppendPaddedString(mLineBuilder, label, 0);
TextUtil.AppendPaddedString(mLineBuilder, opcode, mColumnWidths[0]);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
TextUtil.AppendPaddedString(mLineBuilder, operand,
Change the way the "add padded string" functions work The functions started by trying to pad a column out to a width, then changed to pad things to a certain length. What they really should be doing is padding the start of an entry to a specified column. This is much more natural and avoids a trim operation. The only change to the output is to ORG statements from the HTML exporter, which are now formatted correctly.
2019-09-18 05:02:05 +00:00
mColumnWidths[0] + mColumnWidths[1]);
TextUtil.AppendPaddedString(mLineBuilder, comment,
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
mColumnWidths[0] + mColumnWidths[1] + mColumnWidths[2]);
mOutStream.WriteLine(mLineBuilder.ToString());
}
private void OutputString(int offset, string labelStr, string commentStr) {
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
// Generic strings whose encoding matches the configured text encoding are output
// with a simple .text directive.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
//
// CString and L8String have directives (.null, .ptext), but we can only use
// them if the string fits on one line and doesn't include delimiters.
//
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
// We might be able to define a macro for Reverse.
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
//
// We don't currently switch character encodings in the middle of a file. We could
// do so to flip between PETSCII, screen codes, low ASCII, and high ASCII, but it
// adds a lot of noise and it's unclear that this is generally useful.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Anattrib attr = Project.GetAnattrib(offset);
FormatDescriptor dfd = attr.DataDescriptor;
Debug.Assert(dfd != null);
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
Debug.Assert(dfd.IsString);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Debug.Assert(dfd.Length > 0);
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
CharEncoding.Convert charConv = null;
CharEncoding.Convert dciConv = null;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
switch (dfd.FormatSubType) {
case FormatDescriptor.SubType.Ascii:
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
charConv = CharEncoding.ConvertAscii;
dciConv = CharEncoding.ConvertLowAndHighAscii;
break;
case FormatDescriptor.SubType.HighAscii:
charConv = CharEncoding.ConvertHighAscii;
dciConv = CharEncoding.ConvertLowAndHighAscii;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
break;
case FormatDescriptor.SubType.C64Petscii:
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
charConv = CharEncoding.ConvertC64Petscii;
dciConv = CharEncoding.ConvertLowAndHighC64Petscii;
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
break;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
case FormatDescriptor.SubType.C64Screen:
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
charConv = CharEncoding.ConvertC64ScreenCode;
dciConv = CharEncoding.ConvertLowAndHighC64ScreenCode;
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
break;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
default:
Generate C64 encodings in 64tass output The 64tass generator now uses the "default text encoding" project property to determine how readable text should be encoded. For example, if the property is set to PETSCII, an ASCII-to-PETSCII encoding table is generated at the top of the output file.
2019-08-16 21:46:17 +00:00
break;
}
if (charConv == null) {
OutputNoJoy(offset, dfd.Length, labelStr, commentStr);
return;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
}
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
// Issue a .enc, if needed.
UpdateCharacterEncoding(dfd);
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
Formatter formatter = SourceFormatter;
byte[] data = Project.FileData;
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
int hiddenLeadingBytes = 0;
int shownLeadingBytes = 0;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
int trailingBytes = 0;
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
string opcodeStr;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
switch (dfd.FormatType) {
case FormatDescriptor.Type.StringGeneric:
case FormatDescriptor.Type.StringReverse:
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = sDataOpNames.StrGeneric;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
break;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
case FormatDescriptor.Type.StringNullTerm:
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = sDataOpNames.StrNullTerm;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
trailingBytes = 1;
break;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
case FormatDescriptor.Type.StringL8:
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = sDataOpNames.StrLen8;
hiddenLeadingBytes = 1;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
break;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
case FormatDescriptor.Type.StringL16:
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = sDataOpNames.StrGeneric;
shownLeadingBytes = 2;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
break;
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
case FormatDescriptor.Type.StringDci:
opcodeStr = sDataOpNames.StrDci;
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
if ((Project.FileData[offset] & 0x80) != 0) {
// ".shift" directive only works for strings where the low bit starts
// clear and ends high.
OutputNoJoy(offset, dfd.Length, labelStr, commentStr);
return;
}
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
break;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
default:
Debug.Assert(false);
return;
}
Replace on-screen string operand formatting The previous functions just grabbed 62 characters and slapped quotes on the ends, but that doesn't work if we want to show strings with embedded control characters. This change replaces the simple formatter with the one used to generate assembly source code. This increases the cost of refreshing the display list, so a cache will need to be added in a future change. Converters for C64 PETSCII and C64 Screen Code have been defined. The results of changing the auto-scan encoding can now be viewed. The string operand formatter was using a single delimiter, but for the on-screen version we want open-quote and close-quote, and might want to identify some encodings with a prefix. The formatter now takes a class that defines the various parts. (It might be worth replacing the delimiter patterns recently added for single-character operands with this, so we don't have two mechanisms for very nearly the same thing.) While working on this change I remembered why there were two kinds of "reverse" in the old Merlin 32 string operand generator: what you want for assembly code is different from what you want on screen. The ReverseMode enum has been resurrected.
2019-08-14 00:22:21 +00:00
StringOpFormatter stropf = new StringOpFormatter(SourceFormatter,
Formatter.DOUBLE_QUOTE_DELIM,StringOpFormatter.RawOutputStyle.CommaSep,
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
MAX_OPERAND_LEN, charConv);
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
if (dfd.FormatType == FormatDescriptor.Type.StringDci) {
// DCI is awkward because the character encoding flips on the last byte. Rather
// than clutter up StringOpFormatter for this rare item, we just accept low/high
// throughout.
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
stropf.CharConv = dciConv;
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
}
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
// Feed bytes in, skipping over hidden bytes (leading L8, trailing null).
stropf.FeedBytes(data, offset + hiddenLeadingBytes,
Replace on-screen string operand formatting The previous functions just grabbed 62 characters and slapped quotes on the ends, but that doesn't work if we want to show strings with embedded control characters. This change replaces the simple formatter with the one used to generate assembly source code. This increases the cost of refreshing the display list, so a cache will need to be added in a future change. Converters for C64 PETSCII and C64 Screen Code have been defined. The results of changing the auto-scan encoding can now be viewed. The string operand formatter was using a single delimiter, but for the on-screen version we want open-quote and close-quote, and might want to identify some encodings with a prefix. The formatter now takes a class that defines the various parts. (It might be worth replacing the delimiter patterns recently added for single-character operands with this, so we don't have two mechanisms for very nearly the same thing.) While working on this change I remembered why there were two kinds of "reverse" in the old Merlin 32 string operand generator: what you want for assembly code is different from what you want on screen. The ReverseMode enum has been resurrected.
2019-08-14 00:22:21 +00:00
dfd.Length - hiddenLeadingBytes - trailingBytes, shownLeadingBytes,
StringOpFormatter.ReverseMode.Forward);
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
Debug.Assert(stropf.Lines.Count > 0);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
// See if we need to do this over.
bool redo = false;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
switch (dfd.FormatType) {
case FormatDescriptor.Type.StringGeneric:
case FormatDescriptor.Type.StringReverse:
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
case FormatDescriptor.Type.StringL16:
// All good the first time.
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
break;
Change the way string formats are defined We used to use type="String", with the sub-type indicating whether the string was null-terminated, prefixed with a length, or whatever. This didn't leave much room for specifying a character encoding, which is orthogonal to the sub-type. What we actually want is to have the type specify the string type, and then have the sub-type determine the character encoding. These sub-types can also be used with the Numeric type to specify the encoding of character operands. This change updates the enum definitions and the various bits of code that use them, but does not add any code for working with non-ASCII character encodings. The project file version number was incremented to 2, since the new FormatDescriptor serialization is mildly incompatible with the old. (Won't explode, but it'll post a complaint and ignore the stuff it doesn't recognize.) While I was at it, I finished removing DciReverse. It's still part of the 2005-string-types regression test, which currently fails because the generated source doesn't match.
2019-08-07 22:23:23 +00:00
case FormatDescriptor.Type.StringNullTerm:
case FormatDescriptor.Type.StringL8:
Improve 64tass output DCI is handled with the ".shift" pseudo-op. The .null, .ptext, and .shift operators all work correctly with escaped characters, so we no longer redo those.
2019-08-10 02:13:58 +00:00
case FormatDescriptor.Type.StringDci:
if (stropf.Lines.Count != 1) {
// Must be single-line.
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = sDataOpNames.StrGeneric;
Update source generators to recognize C64 strings For the most part this means explicitly dumping them as hex, though ACME gets to exercise its !pet and !scr operators.
2019-08-16 04:33:10 +00:00
stropf.CharConv = charConv; // undo DCI hack
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
redo = true;
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
}
break;
default:
Debug.Assert(false);
return;
}
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
if (redo) {
//Debug.WriteLine("REDO off=+" + offset.ToString("x6") + ": " + dfd.FormatType);
// This time, instead of skipping over leading length bytes, we include them
// explicitly.
stropf.Reset();
Replace on-screen string operand formatting The previous functions just grabbed 62 characters and slapped quotes on the ends, but that doesn't work if we want to show strings with embedded control characters. This change replaces the simple formatter with the one used to generate assembly source code. This increases the cost of refreshing the display list, so a cache will need to be added in a future change. Converters for C64 PETSCII and C64 Screen Code have been defined. The results of changing the auto-scan encoding can now be viewed. The string operand formatter was using a single delimiter, but for the on-screen version we want open-quote and close-quote, and might want to identify some encodings with a prefix. The formatter now takes a class that defines the various parts. (It might be worth replacing the delimiter patterns recently added for single-character operands with this, so we don't have two mechanisms for very nearly the same thing.) While working on this change I remembered why there were two kinds of "reverse" in the old Merlin 32 string operand generator: what you want for assembly code is different from what you want on screen. The ReverseMode enum has been resurrected.
2019-08-14 00:22:21 +00:00
stropf.FeedBytes(data, offset, dfd.Length, hiddenLeadingBytes,
StringOpFormatter.ReverseMode.Forward);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
}
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
opcodeStr = formatter.FormatPseudoOp(opcodeStr);
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
Rework string operand formatting This generalizes the string pseudo-operand formatter, moving it into the Asm65 library. The assembly source generators have been updated to use it. This makes the individual generators simpler, and by virtue of avoiding "test runs" should make them slightly faster. This also introduces byte-to-character converters, though we're currently still only supporting low/high ASCII. Regression test output is unchanged.
2019-08-09 23:42:30 +00:00
foreach (string str in stropf.Lines) {
OutputLine(labelStr, opcodeStr, str, commentStr);
labelStr = commentStr = string.Empty; // only show on first
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
}
}
}
#endregion IGenerator
#region IAssembler
/// <summary>
/// Cross-assembler execution interface.
/// </summary>
public class AsmTass64 : IAssembler {
Change the way ASCII is handled for 64tass The documentation for 64tass says you're required to pass "--ascii" when the source file is ASCII (as opposed to PETSCII). We were ignoring this, but it turns out that everything works a bit better if we don't. So we now pass "--ascii" on the command line, and add a two-line character encoding definition to every file that is generated with ASCII as the default encoding. The sg_petscii and sg_screen encodings go away, as PETSCII is now the default, and we can use the built-in "screen" encoding.
2019-08-20 18:21:30 +00:00
// Standard options. For historical reasons the assembler expects PETSCII input by
// default, and requires "--ascii" for ASCII/UTF-8 input. This flag switches the
// default "none" encoding from "raw" to something that converts characters to
// PETSCII, so if you want to output strings in another format (such as ASCII) an
// explicit encoding must be specified.
public const string OPTIONS = "--ascii --case-sensitive --nostart --long-address -Wall";
Show formatted data in the code list The disassembled lines are now shown in the custom-styled list view. The DisplayList isn't being kept up to date on edits, but since we can't edit anything yet that's not too limiting. Pulled more code over, including the mostly-GUI-agnostic bits of the source generation and assembler execution code.
2019-05-28 01:46:09 +00:00
// Paths from generator.
private List<string> mPathNames;
// Directory to make current before executing assembler.
private string mWorkDirectory;
// IAssembler
public void GetExeIdentifiers(out string humanName, out string exeName) {
humanName = "64tass Assembler";
exeName = "64tass";
}
// IAssembler
public AssemblerConfig GetDefaultConfig() {
return new AssemblerConfig(string.Empty, new int[] { 8, 8, 11, 73 });
}
// IAssembler
public AssemblerVersion QueryVersion() {
AssemblerConfig config =
AssemblerConfig.GetConfig(AppSettings.Global, AssemblerInfo.Id.Tass64);
if (config == null || string.IsNullOrEmpty(config.ExecutablePath)) {
return null;
}
ShellCommand cmd = new ShellCommand(config.ExecutablePath, "--version",
Directory.GetCurrentDirectory(), null);
cmd.Execute();
if (string.IsNullOrEmpty(cmd.Stdout)) {
return null;
}
// Windows - Stdout: "64tass Turbo Assembler Macro V1.53.1515\r\n"
// Linux - Stdout: "64tass Turbo Assembler Macro V1.53.1515?\n"
const string PREFIX = "Macro V";
string str = cmd.Stdout;
int start = str.IndexOf(PREFIX);
int end = (start < 0) ? -1 : str.IndexOfAny(new char[] { '?', '\r', '\n' }, start + 1);
if (start < 0 || end < 0 || start + PREFIX.Length >= end) {
Debug.WriteLine("Couldn't find version in " + str);
return null;
}
start += PREFIX.Length;
string versionStr = str.Substring(start, end - start);
CommonUtil.Version version = CommonUtil.Version.Parse(versionStr);
if (!version.IsValid) {
return null;
}
return new AssemblerVersion(versionStr, version);
}
// IAssembler
public void Configure(List<string> pathNames, string workDirectory) {
// Clone pathNames, in case the caller decides to modify the original.
mPathNames = new List<string>(pathNames.Count);
foreach (string str in pathNames) {
mPathNames.Add(str);
}
mWorkDirectory = workDirectory;
}
// IAssembler
public AssemblerResults RunAssembler(BackgroundWorker worker) {
// Reduce input file to a partial path if possible. This is really just to make
// what we display to the user a little easier to read.
string pathName = mPathNames[0];
if (pathName.StartsWith(mWorkDirectory)) {
pathName = pathName.Remove(0, mWorkDirectory.Length + 1);
} else {
// Unexpected, but shouldn't be a problem.
Debug.WriteLine("NOTE: source file is not in work directory");
}
AssemblerConfig config =
AssemblerConfig.GetConfig(AppSettings.Global, AssemblerInfo.Id.Tass64);
if (string.IsNullOrEmpty(config.ExecutablePath)) {
Debug.WriteLine("Assembler not configured");
return null;
}
worker.ReportProgress(0, Res.Strings.PROGRESS_ASSEMBLING);
string outFileName = pathName.Substring(0, pathName.Length - 2);
// Wrap pathname in quotes in case it has spaces.
// (Do we need to shell-escape quotes in the pathName?)
ShellCommand cmd = new ShellCommand(config.ExecutablePath,
OPTIONS + " \"" + pathName + "\"" + " -o \"" + outFileName + "\"",
mWorkDirectory, null);
cmd.Execute();
// Can't really do anything with a "cancel" request.
// Output filename is the input filename without the ".S". Since the filename
// was generated by us we can be confident in the format.
string outputFile = mPathNames[0].Substring(0, mPathNames[0].Length - 2);
return new AssemblerResults(cmd.FullCommandLine, cmd.ExitCode, cmd.Stdout,
cmd.Stderr, outputFile);
}
}
#endregion IAssembler
}
Reference in New Issue Copy Permalink