2019-07-06 21:20:51 +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.RegularExpressions;
|
|
|
|
|
using System.Windows.Media;
|
2020-06-07 23:28:29 +00:00
|
|
|
|
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
using Asm65;
|
2019-07-06 21:20:51 +00:00
|
|
|
|
using CommonUtil;
|
2019-07-20 20:28:10 +00:00
|
|
|
|
using SourceGen.AsmGen;
|
2019-07-06 21:20:51 +00:00
|
|
|
|
|
2019-07-20 20:28:10 +00:00
|
|
|
|
namespace SourceGen.Tests {
|
2019-07-06 21:20:51 +00:00
|
|
|
|
/// <summary>
|
|
|
|
|
/// Source code generation regression test.
|
|
|
|
|
///
|
|
|
|
|
/// The generator is tested in two ways: (1) by comparing the output to known-good
|
|
|
|
|
/// sources, and (2) by running it through the assembler. Assembling the sources is
|
|
|
|
|
/// important to ensure that we don't get bad sources in the "known-good" set.
|
|
|
|
|
///
|
|
|
|
|
/// This does not take assembler version into account, so it will not be helpful for
|
|
|
|
|
/// monitoring compatibility with old versions of assemblers.
|
|
|
|
|
/// </summary>
|
|
|
|
|
public class GenTest {
|
|
|
|
|
private const string TEST_DIR_NAME = "SGTestData";
|
|
|
|
|
private const string EXPECTED_DIR_NAME = "Expected";
|
|
|
|
|
|
|
|
|
|
//private static char[] sInvalidChars = new char[] { '.', '_' };
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
private const string TestCasePattern = @"^\d\d\d\d\d-[A-Za-z0-9-]+$";
|
2019-07-06 21:20:51 +00:00
|
|
|
|
private static Regex sTestCaseRegex = new Regex(TestCasePattern);
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Whitelist of removable names for ScrubWorkDirectory().
|
|
|
|
|
/// </summary>
|
|
|
|
|
private static string[] sScrubList = new string[] {
|
|
|
|
|
"_FileInformation.txt", // created by Merlin 32
|
|
|
|
|
"error_output.txt", // created by Merlin 32 (only when errors found)
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Test result. One of these will be created for every {test-case, assembler} pair.
|
|
|
|
|
/// </summary>
|
|
|
|
|
public class GenTestResults {
|
|
|
|
|
public string PathName { get; private set; }
|
|
|
|
|
public string FileName { get; private set; }
|
|
|
|
|
public AssemblerInfo.Id AsmId { get; private set; }
|
|
|
|
|
|
|
|
|
|
public FileLoadReport ProjectLoadReport { get; set; }
|
|
|
|
|
|
|
|
|
|
public bool GenerateOkay { get; set; }
|
|
|
|
|
public bool AssembleOkay { get; set; }
|
|
|
|
|
public AssemblerResults AsmResults { get; set; } // may be null
|
|
|
|
|
|
|
|
|
|
public TaskTimer Timer { get; set; } // may be null
|
|
|
|
|
|
|
|
|
|
public GenTestResults(string pathName, AssemblerInfo.Id asmId) {
|
|
|
|
|
PathName = pathName;
|
|
|
|
|
AsmId = asmId;
|
|
|
|
|
|
|
|
|
|
FileName = Path.GetFileName(pathName);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Return a string for use in the UI combo box.
|
|
|
|
|
public override string ToString() {
|
|
|
|
|
return (GenerateOkay && AssembleOkay ? "OK" : "FAIL") + " - " +
|
|
|
|
|
FileName + " - " + AsmId.ToString();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// If true, don't scrub directories.
|
|
|
|
|
/// </summary>
|
|
|
|
|
public bool RetainOutput { get; set; }
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Directory with test cases.
|
|
|
|
|
/// </summary>
|
|
|
|
|
private string mTestDir;
|
|
|
|
|
|
|
|
|
|
private BackgroundWorker mWorker;
|
|
|
|
|
|
|
|
|
|
private List<GenTestResults> mResults = new List<GenTestResults>();
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Runs generate/assemble test cases. Main entry point.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="worker">Background worker object from dialog box.</param>
|
|
|
|
|
public List<GenTestResults> Run(BackgroundWorker worker) {
|
|
|
|
|
Debug.Assert(mWorker == null); // don't re-use object
|
|
|
|
|
|
|
|
|
|
mWorker = worker;
|
|
|
|
|
string runtimeDir = RuntimeDataAccess.GetDirectory();
|
|
|
|
|
mTestDir = Path.Combine(Path.GetDirectoryName(runtimeDir), TEST_DIR_NAME);
|
|
|
|
|
|
|
|
|
|
if (!Directory.Exists(mTestDir)) {
|
|
|
|
|
ReportErrMsg("Regression test directory not found: " + mTestDir);
|
|
|
|
|
ReportFailure();
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
List<string> testCases = new List<string>();
|
|
|
|
|
foreach (string pathName in Directory.EnumerateFiles(mTestDir)) {
|
|
|
|
|
// Filter out everything that doesn't look like "1000-nifty-test". We
|
|
|
|
|
// want to ignore .dis65 files and assembler output (which has the name
|
|
|
|
|
// of the assembler following an underscore).
|
|
|
|
|
string fileName = Path.GetFileName(pathName);
|
|
|
|
|
MatchCollection matches = sTestCaseRegex.Matches(fileName);
|
|
|
|
|
if (matches.Count == 0) {
|
|
|
|
|
//ReportProgress("Ignoring " + fileName + "\r\n", Color.Gray);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReportProgress("Found " + fileName + "\r\n");
|
|
|
|
|
testCases.Add(pathName);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReportProgress("Processing " + testCases.Count + " test cases...\r\n");
|
|
|
|
|
DateTime startWhen = DateTime.Now;
|
|
|
|
|
|
|
|
|
|
int successCount = 0;
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
int asmFailCount = 0;
|
2019-07-06 21:20:51 +00:00
|
|
|
|
foreach (string pathName in testCases) {
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
if (GenerateAndAssemble(pathName, out bool someAsmFailed)) {
|
2019-07-06 21:20:51 +00:00
|
|
|
|
successCount++;
|
|
|
|
|
}
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
if (someAsmFailed) {
|
|
|
|
|
asmFailCount++;
|
|
|
|
|
}
|
2019-07-06 21:20:51 +00:00
|
|
|
|
|
|
|
|
|
if (worker.CancellationPending) {
|
|
|
|
|
ReportProgress("\r\nCancelled.\r\n", Colors.Red);
|
|
|
|
|
return mResults;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DateTime endWhen = DateTime.Now;
|
|
|
|
|
|
|
|
|
|
if (successCount == testCases.Count) {
|
|
|
|
|
ReportProgress(string.Format("All " + testCases.Count +
|
|
|
|
|
" tests passed in {0:N3} sec\r\n",
|
|
|
|
|
(endWhen - startWhen).TotalSeconds), Colors.Green);
|
|
|
|
|
} else {
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
ReportProgress(successCount + " of " + testCases.Count + " tests passed\r\n",
|
|
|
|
|
Colors.OrangeRed);
|
|
|
|
|
ReportProgress(asmFailCount + " tests reported assembler failures\r\n");
|
2019-07-06 21:20:51 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-07-31 21:42:36 +00:00
|
|
|
|
PrintAsmVersions();
|
|
|
|
|
|
2019-07-06 21:20:51 +00:00
|
|
|
|
return mResults;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void ReportProgress(string msg) {
|
|
|
|
|
mWorker.ReportProgress(0, new ProgressMessage(msg));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void ReportProgress(string msg, Color color) {
|
|
|
|
|
mWorker.ReportProgress(0, new ProgressMessage(msg, color));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void ReportErrMsg(string msg) {
|
|
|
|
|
ReportProgress(" [" + msg + "] ", Colors.Blue);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void ReportSuccess() {
|
|
|
|
|
ReportProgress(" success\r\n", Colors.Green);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void ReportFailure() {
|
|
|
|
|
ReportProgress(" failed\r\n", Colors.Red);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Extracts the test's number from the pathname.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="pathName">Full or partial path to test file.</param>
|
|
|
|
|
/// <returns>Test number.</returns>
|
|
|
|
|
private int GetTestNum(string pathName) {
|
|
|
|
|
// Should always succeed if pathName matched on our regex.
|
|
|
|
|
string fileName = Path.GetFileName(pathName);
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
return int.Parse(fileName.Substring(0, 5));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Determines the desired CPU from the test case number.
|
|
|
|
|
/// </summary>
|
2020-10-11 01:34:19 +00:00
|
|
|
|
/// <param name="testNum">Test number.</param>
|
|
|
|
|
/// <returns>CPU type enumeration value.</returns>
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
private CpuDef.CpuType GetCpuTypeFromNum(int testNum) {
|
|
|
|
|
switch (testNum % 10) {
|
|
|
|
|
case 0: return CpuDef.CpuType.Cpu6502;
|
|
|
|
|
case 1: return CpuDef.CpuType.Cpu65C02;
|
|
|
|
|
case 2: return CpuDef.CpuType.Cpu65816;
|
2020-10-11 01:34:19 +00:00
|
|
|
|
case 3: return CpuDef.CpuType.CpuW65C02;
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
default: return CpuDef.CpuType.CpuUnknown;
|
|
|
|
|
}
|
2019-07-06 21:20:51 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Generates source code for the specified test case, assembles it, and compares
|
|
|
|
|
/// the output of both steps to expected values. The process is repeated for every
|
|
|
|
|
/// known assembler.
|
|
|
|
|
///
|
|
|
|
|
/// If an assembler is known but not configured, the assembly step is skipped, and
|
|
|
|
|
/// does not count as a failure.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="pathName">Full path to test case.</param>
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
/// <param name="someAsmFailed">Set to true if one or more assemblers reported an error,
|
|
|
|
|
/// or the assembled binary did not match. Useful when running the tests against an
|
|
|
|
|
/// older version of an assembler for which the generated code does not match the
|
|
|
|
|
/// expected text, but we can still evaluate correctness.</param>
|
2019-07-06 21:20:51 +00:00
|
|
|
|
/// <returns>True if all assemblers worked as expected.</returns>
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
private bool GenerateAndAssemble(string pathName, out bool someAsmFailed) {
|
|
|
|
|
someAsmFailed = false;
|
|
|
|
|
|
2019-07-06 21:20:51 +00:00
|
|
|
|
ReportProgress(Path.GetFileName(pathName) + "...\r\n");
|
|
|
|
|
|
|
|
|
|
// Create DisasmProject object, either as a new project for a plain data file,
|
|
|
|
|
// or from a project file.
|
|
|
|
|
DisasmProject project = InstantiateProject(pathName,
|
|
|
|
|
out FileLoadReport projectLoadReport);
|
|
|
|
|
if (project == null) {
|
|
|
|
|
ReportFailure();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int testNum = GetTestNum(pathName);
|
|
|
|
|
|
|
|
|
|
// Create a temporary directory to work in.
|
|
|
|
|
string workDir = CreateWorkDirectory(pathName);
|
|
|
|
|
if (string.IsNullOrEmpty(workDir)) {
|
|
|
|
|
ReportFailure();
|
|
|
|
|
project.Cleanup();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AppSettings settings = CreateNormalizedSettings();
|
|
|
|
|
ApplyProjectSettings(settings, project);
|
|
|
|
|
|
|
|
|
|
// Iterate through all known assemblers.
|
|
|
|
|
bool didFail = false;
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
int numAsmFailures = 0;
|
2019-07-06 21:20:51 +00:00
|
|
|
|
foreach (AssemblerInfo.Id asmId in
|
|
|
|
|
(AssemblerInfo.Id[])Enum.GetValues(typeof(AssemblerInfo.Id))) {
|
|
|
|
|
if (asmId == AssemblerInfo.Id.Unknown) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
string fileName = Path.GetFileName(pathName);
|
|
|
|
|
TaskTimer timer = new TaskTimer();
|
|
|
|
|
timer.StartTask("Full Test Duration");
|
|
|
|
|
|
|
|
|
|
// Create results object and add it to the list. We'll add stuff to it for
|
|
|
|
|
// as far as we get.
|
|
|
|
|
GenTestResults results = new GenTestResults(pathName, asmId);
|
|
|
|
|
mResults.Add(results);
|
|
|
|
|
results.ProjectLoadReport = projectLoadReport;
|
|
|
|
|
|
|
|
|
|
// Generate source code.
|
|
|
|
|
ReportProgress(" " + asmId.ToString() + " generate...");
|
|
|
|
|
IGenerator gen = AssemblerInfo.GetGenerator(asmId);
|
|
|
|
|
if (gen == null) {
|
|
|
|
|
ReportErrMsg("generator unavailable");
|
|
|
|
|
ReportProgress("\r\n");
|
|
|
|
|
//didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
timer.StartTask("Generate Source");
|
|
|
|
|
gen.Configure(project, workDir, fileName,
|
|
|
|
|
AssemblerVersionCache.GetVersion(asmId), settings);
|
2020-10-17 23:10:48 +00:00
|
|
|
|
GenerationResults genResults = gen.GenerateSource(mWorker);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
timer.EndTask("Generate Source");
|
|
|
|
|
if (mWorker.CancellationPending) {
|
|
|
|
|
// The generator will stop early if a cancellation is requested. If we
|
|
|
|
|
// don't break here, the compare function will report a failure, which
|
|
|
|
|
// isn't too problematic but looks funny.
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReportProgress(" verify...");
|
|
|
|
|
timer.StartTask("Compare Source to Expected");
|
2020-10-17 23:10:48 +00:00
|
|
|
|
bool match = CompareGeneratedToExpected(pathName, genResults.PathNames);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
timer.EndTask("Compare Source to Expected");
|
|
|
|
|
if (match) {
|
|
|
|
|
ReportSuccess();
|
|
|
|
|
results.GenerateOkay = true;
|
|
|
|
|
} else {
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
|
|
|
|
|
// The fact that it doesn't match the expected sources doesn't mean it's
|
|
|
|
|
// invalid. Go ahead and try to build it.
|
|
|
|
|
//continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Assemble code.
|
|
|
|
|
ReportProgress(" " + asmId.ToString() + " assemble...");
|
|
|
|
|
IAssembler asm = AssemblerInfo.GetAssembler(asmId);
|
|
|
|
|
if (asm == null) {
|
|
|
|
|
ReportErrMsg("assembler unavailable");
|
|
|
|
|
ReportProgress("\r\n");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
timer.StartTask("Assemble Source");
|
2020-10-17 23:10:48 +00:00
|
|
|
|
asm.Configure(genResults, workDir);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
AssemblerResults asmResults = asm.RunAssembler(mWorker);
|
|
|
|
|
timer.EndTask("Assemble Source");
|
|
|
|
|
if (asmResults == null) {
|
|
|
|
|
ReportErrMsg("unable to run assembler");
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
results.AsmResults = asmResults;
|
|
|
|
|
numAsmFailures++; // assume failure until the end
|
2019-07-06 21:20:51 +00:00
|
|
|
|
if (asmResults.ExitCode != 0) {
|
|
|
|
|
ReportErrMsg("assembler returned code=" + asmResults.ExitCode);
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReportProgress(" verify...");
|
|
|
|
|
timer.StartTask("Compare Binary to Expected");
|
|
|
|
|
FileInfo fi = new FileInfo(asmResults.OutputPathName);
|
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 (!fi.Exists) {
|
|
|
|
|
// This can happen if the assembler fails to generate output but doesn't
|
|
|
|
|
// report an error code (e.g. Merlin 32 in certain situations).
|
|
|
|
|
ReportErrMsg("asm output missing");
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
} else if (fi.Length != project.FileData.Length) {
|
2019-07-06 21:20:51 +00:00
|
|
|
|
ReportErrMsg("asm output mismatch: length is " + fi.Length + ", expected " +
|
|
|
|
|
project.FileData.Length);
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
} else if (!FileUtil.CompareBinaryFile(project.FileData, asmResults.OutputPathName,
|
|
|
|
|
out int badOffset, out byte badFileVal)) {
|
|
|
|
|
ReportErrMsg("asm output mismatch: offset +" + badOffset.ToString("x6") +
|
|
|
|
|
" has value $" + badFileVal.ToString("x2") + ", expected $" +
|
|
|
|
|
project.FileData[badOffset].ToString("x2"));
|
|
|
|
|
ReportFailure();
|
|
|
|
|
didFail = true;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
timer.EndTask("Compare Binary to Expected");
|
|
|
|
|
|
|
|
|
|
// Victory!
|
|
|
|
|
results.AssembleOkay = true;
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
numAsmFailures--;
|
2019-07-06 21:20:51 +00:00
|
|
|
|
ReportSuccess();
|
|
|
|
|
|
|
|
|
|
timer.EndTask("Full Test Duration");
|
|
|
|
|
results.Timer = timer;
|
|
|
|
|
|
|
|
|
|
// We don't scrub the directory on success at this point. We could, but we'd
|
|
|
|
|
// need to remove only those files associated with the currently assembler.
|
|
|
|
|
// Otherwise, a failure followed by a success would wipe out the unsuccessful
|
|
|
|
|
// temporaries.
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If something failed, leave the bits around for examination. Otherwise, try to
|
|
|
|
|
// remove the directory and all its contents.
|
|
|
|
|
if (!didFail && !RetainOutput) {
|
|
|
|
|
ScrubWorkDirectory(workDir, testNum);
|
|
|
|
|
RemoveWorkDirectory(workDir);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
project.Cleanup();
|
Fix 64tass output for non-loadable files
64tass wants to place its output into a 64KB region of memory,
starting at the address "*" is set to, and continuing without
wrapping around the end of the bank. Some files aren't meant to be
handled that way, so we need to generate the output differently.
If the file's output fits nicely, it's considered "loadable", and
is generated in the usual way. If it doesn't, it's treated as
"streamable", and the initial "* = addr" directive is omitted
(leaving "*" at zero), and we go straight to ".logical" directives.
65816 code with an initial address outside bank 0 is treated as
"streamable" whether or not the contents fit nicely in the designated
64K area. This caused a minor change to a few of the 65816 tests.
A new test, 20240-large-overlay, exercises "streamable" by creating
a file with eight overlapping 8KB segments that load at $8000.
While the file as a whole fits in 64KB, it wouldn't if loaded at
the desired start address.
Also, updated the regression test harness to report assembler
failure independently of overall test failure. This makes it easier
to confirm that (say) ACME v0.96.4 still works with the code we
generate, even though it doesn't match the expected output (which
was generated for v0.97).
(problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
|
|
|
|
|
|
|
|
|
someAsmFailed = (numAsmFailures != 0);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
return !didFail;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-31 21:42:36 +00:00
|
|
|
|
private void PrintAsmVersions() {
|
|
|
|
|
ReportProgress("\nTested assemblers:");
|
|
|
|
|
IEnumerator<AssemblerInfo> iter = AssemblerInfo.GetInfoEnumerator();
|
|
|
|
|
while (iter.MoveNext()) {
|
|
|
|
|
AssemblerInfo info = iter.Current;
|
|
|
|
|
AssemblerVersion version = AssemblerVersionCache.GetVersion(info.AssemblerId);
|
|
|
|
|
ReportProgress(" " + info.Name + " v" + version.VersionStr);
|
|
|
|
|
}
|
|
|
|
|
ReportProgress("\n");
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-06 21:20:51 +00:00
|
|
|
|
/// <summary>
|
|
|
|
|
/// Gets a copy of the AppSettings with a standard set of formatting options (e.g. lower
|
|
|
|
|
/// case for everything).
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <returns>New app settings object.</returns>
|
|
|
|
|
private AppSettings CreateNormalizedSettings() {
|
|
|
|
|
AppSettings settings = AppSettings.Global.GetCopy();
|
|
|
|
|
|
|
|
|
|
// Override all asm formatting options. We can ignore ShiftBeforeAdjust and the
|
|
|
|
|
// pseudo-op names because those are set by the generators.
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_HEX_DIGITS, false);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_OP_MNEMONIC, false);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_PSEUDO_OP_MNEMONIC, false);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_OPERAND_A, true);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_OPERAND_S, true);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_UPPER_OPERAND_XY, false);
|
|
|
|
|
settings.SetBool(AppSettings.FMT_ADD_SPACE_FULL_COMMENT, false);
|
2020-07-20 01:39:27 +00:00
|
|
|
|
settings.SetInt(AppSettings.FMT_OPERAND_WRAP_LEN, 64);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
|
|
|
|
|
// Don't show the assembler ident line. You can make a case for this being
|
|
|
|
|
// mandatory, since the generated code is only guaranteed to work with the
|
|
|
|
|
// assembler for which it was targeted, but I expect we'll quickly get to a
|
|
|
|
|
// place where we don't have to work around assembler bugs, and this will just
|
|
|
|
|
// become a nuisance.
|
|
|
|
|
settings.SetBool(AppSettings.SRCGEN_ADD_IDENT_COMMENT, false);
|
|
|
|
|
|
|
|
|
|
// Don't break lines with long labels. That way we can redefine "long"
|
|
|
|
|
// without breaking our tests. (This is purely cosmetic.)
|
|
|
|
|
settings.SetBool(AppSettings.SRCGEN_LONG_LABEL_NEW_LINE, false);
|
|
|
|
|
|
|
|
|
|
// This could be on or off. Off seems less distracting.
|
|
|
|
|
settings.SetBool(AppSettings.SRCGEN_SHOW_CYCLE_COUNTS, false);
|
|
|
|
|
|
|
|
|
|
IEnumerator<AssemblerInfo> iter = AssemblerInfo.GetInfoEnumerator();
|
|
|
|
|
while (iter.MoveNext()) {
|
|
|
|
|
AssemblerInfo.Id asmId = iter.Current.AssemblerId;
|
|
|
|
|
AssemblerConfig curConfig =
|
|
|
|
|
AssemblerConfig.GetConfig(settings, asmId);
|
|
|
|
|
AssemblerConfig defConfig =
|
|
|
|
|
AssemblerInfo.GetAssembler(asmId).GetDefaultConfig();
|
|
|
|
|
|
|
|
|
|
// Merge the two together. We want the default assembler config for most
|
|
|
|
|
// things, but the executable path from the current config.
|
|
|
|
|
defConfig.ExecutablePath = curConfig.ExecutablePath;
|
|
|
|
|
|
|
|
|
|
// Write it into the test settings.
|
|
|
|
|
AssemblerConfig.SetConfig(settings, asmId, defConfig);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return settings;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Applies app setting overrides that were specified in the project settings.
|
|
|
|
|
/// </summary>
|
|
|
|
|
private void ApplyProjectSettings(AppSettings settings, DisasmProject project) {
|
|
|
|
|
// We could probably make this a more general mechanism, but that would strain
|
|
|
|
|
// things a bit, since we need to know the settings name, bool/int/string, and
|
|
|
|
|
// desired value. Easier to just have a set of named features.
|
|
|
|
|
const string ENABLE_LABEL_NEWLINE = "__ENABLE_LABEL_NEWLINE";
|
2019-09-15 01:51:03 +00:00
|
|
|
|
const string ENABLE_CYCLE_COUNTS = "__ENABLE_CYCLE_COUNTS";
|
2019-07-06 21:20:51 +00:00
|
|
|
|
|
|
|
|
|
if (project.ProjectProps.ProjectSyms.ContainsKey(ENABLE_LABEL_NEWLINE)) {
|
|
|
|
|
settings.SetBool(AppSettings.SRCGEN_LONG_LABEL_NEW_LINE, true);
|
|
|
|
|
}
|
2019-09-15 01:51:03 +00:00
|
|
|
|
if (project.ProjectProps.ProjectSyms.ContainsKey(ENABLE_CYCLE_COUNTS)) {
|
|
|
|
|
settings.SetBool(AppSettings.SRCGEN_SHOW_CYCLE_COUNTS, true);
|
|
|
|
|
}
|
2019-07-06 21:20:51 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private DisasmProject InstantiateProject(string dataPathName,
|
|
|
|
|
out FileLoadReport projectLoadReport) {
|
|
|
|
|
DisasmProject project = new DisasmProject();
|
|
|
|
|
// always use AppDomain sandbox
|
|
|
|
|
|
|
|
|
|
projectLoadReport = null;
|
|
|
|
|
|
|
|
|
|
int testNum = GetTestNum(dataPathName);
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
CpuDef.CpuType cpuType = GetCpuTypeFromNum(testNum);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
if (testNum < 20000) {
|
2019-07-06 21:20:51 +00:00
|
|
|
|
// create new disasm project for data file
|
|
|
|
|
byte[] fileData;
|
|
|
|
|
try {
|
|
|
|
|
fileData = LoadDataFile(dataPathName);
|
|
|
|
|
} catch (Exception ex) {
|
|
|
|
|
ReportErrMsg(ex.Message);
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
project.Initialize(fileData.Length);
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
project.ProjectProps.CpuType = cpuType;
|
|
|
|
|
project.ProjectProps.IncludeUndocumentedInstr = true;
|
|
|
|
|
project.ProjectProps.TwoByteBrk = false;
|
|
|
|
|
project.UpdateCpuDef();
|
2019-07-06 21:20:51 +00:00
|
|
|
|
project.PrepForNew(fileData, Path.GetFileName(dataPathName));
|
|
|
|
|
// no platform symbols to load
|
|
|
|
|
} else {
|
|
|
|
|
// deserialize project file, failing if we can't find it
|
|
|
|
|
string projectPathName = dataPathName + ProjectFile.FILENAME_EXT;
|
|
|
|
|
if (!ProjectFile.DeserializeFromFile(projectPathName,
|
|
|
|
|
project, out projectLoadReport)) {
|
|
|
|
|
ReportErrMsg(projectLoadReport.Format());
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
byte[] fileData;
|
|
|
|
|
try {
|
|
|
|
|
fileData = LoadDataFile(dataPathName);
|
|
|
|
|
} catch (Exception ex) {
|
|
|
|
|
ReportErrMsg(ex.Message);
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-10 21:24:19 +00:00
|
|
|
|
FileLoadReport unused = new FileLoadReport("test");
|
|
|
|
|
project.SetFileData(fileData, Path.GetFileName(dataPathName), ref unused);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
project.ProjectPathName = projectPathName;
|
2019-10-08 00:56:35 +00:00
|
|
|
|
string extMsgs = project.LoadExternalFiles();
|
|
|
|
|
if (!string.IsNullOrEmpty(extMsgs)) {
|
|
|
|
|
ReportErrMsg(extMsgs);
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
// keep going
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (project.ProjectProps.CpuType != cpuType) {
|
|
|
|
|
ReportErrMsg("Mismatch CPU type for test " + testNum + ": project wants " +
|
|
|
|
|
project.ProjectProps.CpuType);
|
|
|
|
|
// keep going
|
2019-10-08 00:56:35 +00:00
|
|
|
|
}
|
2019-07-06 21:20:51 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TaskTimer genTimer = new TaskTimer();
|
|
|
|
|
DebugLog genLog = new DebugLog();
|
|
|
|
|
genLog.SetMinPriority(DebugLog.Priority.Silent);
|
|
|
|
|
project.Analyze(UndoableChange.ReanalysisScope.CodeAndData, genLog, genTimer);
|
|
|
|
|
|
|
|
|
|
return project;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Loads the test case data file.
|
|
|
|
|
///
|
|
|
|
|
/// Throws an exception on failure.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="pathName">Full path to test case data file.</param>
|
|
|
|
|
/// <returns>File contents.</returns>
|
|
|
|
|
private byte[] LoadDataFile(string pathName) {
|
|
|
|
|
byte[] fileData;
|
|
|
|
|
|
|
|
|
|
using (FileStream fs = File.Open(pathName, FileMode.Open, FileAccess.Read)) {
|
|
|
|
|
Debug.Assert(fs.Length <= DisasmProject.MAX_DATA_FILE_SIZE);
|
|
|
|
|
fileData = new byte[fs.Length];
|
|
|
|
|
int actual = fs.Read(fileData, 0, (int)fs.Length);
|
|
|
|
|
if (actual != fs.Length) {
|
|
|
|
|
// Not expected -- should be able to read the entire file in one shot.
|
|
|
|
|
throw new Exception(Res.Strings.OPEN_DATA_PARTIAL_READ);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return fileData;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Creates a work directory for the specified test case. The new directory will be
|
|
|
|
|
/// created in the same directory as the test, and named after it.
|
|
|
|
|
///
|
|
|
|
|
/// If the directory already exists, the previous contents will be scrubbed.
|
|
|
|
|
///
|
|
|
|
|
/// If the file already exists but isn't a directory, this will fail.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="pathName">Test case path name.</param>
|
|
|
|
|
/// <returns>Path of work directory, or null if creation failed.</returns>
|
|
|
|
|
private string CreateWorkDirectory(string pathName) {
|
|
|
|
|
string baseDir = Path.GetDirectoryName(pathName);
|
|
|
|
|
int testNum = GetTestNum(pathName);
|
|
|
|
|
string workDirName = "tmp" + testNum.ToString();
|
|
|
|
|
string workDirPath = Path.Combine(baseDir, workDirName);
|
|
|
|
|
if (Directory.Exists(workDirPath)) {
|
|
|
|
|
ScrubWorkDirectory(workDirPath, testNum);
|
|
|
|
|
} else if (File.Exists(workDirPath)) {
|
|
|
|
|
ReportErrMsg("file '" + workDirPath + "' exists, not directory");
|
|
|
|
|
return null;
|
|
|
|
|
} else {
|
|
|
|
|
try {
|
|
|
|
|
Directory.CreateDirectory(workDirPath);
|
|
|
|
|
} catch (Exception ex) {
|
|
|
|
|
ReportErrMsg(ex.Message);
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return workDirPath;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Removes the contents of a temporary work directory. Only files that we believe
|
|
|
|
|
/// to be products of the generator or assembler are removed.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="workDir"></param>
|
|
|
|
|
/// <param name="testNum"></param>
|
|
|
|
|
private void ScrubWorkDirectory(string workDir, int testNum) {
|
|
|
|
|
string checkString = testNum.ToString();
|
Regression test rework, part 1
The regression tests were written with the assumption that all cross
assemblers would support 6502, 65C02, and 65816 code. There are a
few that support 65816 partially (e.g. ACME) or not at all. To best
support these, we need to split some of the tests into pieces, so
that important 6502 tests aren't skipped simply because parts of the
test also exercise 65816 code.
The first step is to change the regression test naming scheme. The
old system used 1xxx for tests without project files, and 2xxx for
tests with project files. The new system uses 1xxxN / 2xxxN, where
N indicates the CPU type: 0 for 6502, 1 for 65C02, and 2 for 65816.
For the 1xxxN tests the new value determines which CPU is used,
which allows us to move the "allops" 6502/65C02 tests into the
no-project category. For 2xxxN it just allows the 6502 and 65816
versions to have the same base name and number.
This change updates the first batch of tests. It involves minor
changes to the test harness and a whole bunch of renaming.
2020-06-06 21:22:53 +00:00
|
|
|
|
if (checkString.Length != 5) {
|
2019-07-06 21:20:51 +00:00
|
|
|
|
Debug.Assert(false);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach (string pathName in Directory.EnumerateFiles(workDir)) {
|
|
|
|
|
bool doRemove = false;
|
|
|
|
|
string fileName = Path.GetFileName(pathName);
|
|
|
|
|
if (fileName.Contains(checkString)) {
|
|
|
|
|
doRemove = true;
|
|
|
|
|
} else {
|
|
|
|
|
foreach (string str in sScrubList) {
|
|
|
|
|
if (fileName == str) {
|
|
|
|
|
doRemove = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!doRemove) {
|
|
|
|
|
ReportErrMsg("not removing '" + fileName + "'");
|
|
|
|
|
continue;
|
|
|
|
|
} else {
|
|
|
|
|
try {
|
|
|
|
|
File.Delete(pathName);
|
|
|
|
|
//Debug.WriteLine("removed " + pathName);
|
|
|
|
|
} catch (Exception ex) {
|
|
|
|
|
ReportErrMsg("unable to remove '" + fileName + "': " + ex.Message);
|
|
|
|
|
// don't stop -- keep trying to remove things
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private void RemoveWorkDirectory(string workDir) {
|
|
|
|
|
try {
|
|
|
|
|
Directory.Delete(workDir);
|
|
|
|
|
} catch (Exception ex) {
|
|
|
|
|
ReportErrMsg("unable to remove work dir: " + ex.Message);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// Compares each file in genFileNames to the corresponding file in Expected.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="pathName">Full pathname of test case.</param>
|
|
|
|
|
/// <param name="genPathNames">List of file names from source generator.</param>
|
|
|
|
|
/// <returns></returns>
|
|
|
|
|
private bool CompareGeneratedToExpected(string pathName, List<string> genPathNames) {
|
|
|
|
|
string expectedDir = Path.Combine(Path.GetDirectoryName(pathName), EXPECTED_DIR_NAME);
|
|
|
|
|
|
|
|
|
|
foreach (string path in genPathNames) {
|
|
|
|
|
string fileName = Path.GetFileName(path);
|
|
|
|
|
string compareName = Path.Combine(expectedDir, fileName);
|
|
|
|
|
|
|
|
|
|
if (!File.Exists(compareName)) {
|
|
|
|
|
// File was generated unexpectedly.
|
|
|
|
|
ReportErrMsg("file '" + fileName + "' not found in " + EXPECTED_DIR_NAME);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Compare the file contents as lines of text. The files may use different
|
|
|
|
|
// line terminators (e.g. LF vs. CRLF), so we can't use file length as a
|
|
|
|
|
// factor.
|
|
|
|
|
if (!FileUtil.CompareTextFiles(path, compareName, out int firstDiffLine,
|
|
|
|
|
out string line1, out string line2)) {
|
|
|
|
|
ReportErrMsg("file '" + fileName + "' differs on line " + firstDiffLine);
|
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
|
|
|
|
|
|
|
|
|
Debug.WriteLine("Difference on line " + firstDiffLine);
|
|
|
|
|
Debug.WriteLine(" generated: " + line1);
|
|
|
|
|
Debug.WriteLine(" expected : " + line2);
|
2019-07-06 21:20:51 +00:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// NOTE: to be thorough, we should check to see if a file exists in Expected
|
|
|
|
|
// that doesn't exist in the work directory. This is slightly more awkward since
|
|
|
|
|
// Expected is a big pile of everything, but we should be able to do it by
|
|
|
|
|
// filtering filenames with the test number.
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|