akkartik
/
mu
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
mu/linux/bootstrap/033check_operands.cc

791 lines
27 KiB
C++
Raw Normal View History

6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
//: Since we're tagging arguments with their types, let's start checking these
//: argument types for each instruction.
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_imm8_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"cd\n" // interrupt ??
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: 'cd' (software interrupt): missing imm8 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
4499 More tweaks for check passes. Ensure they're never first-class transforms.
2018-08-10 04:35:04 +00:00
:(before "Pack Operands(segment code)")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments(code);
4483 Reorganize layers in accordance with the plan in layer 29.
2018-08-05 05:59:47 +00:00
if (trace_contains_errors()) return;
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(code)
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments(const segment& code) {
trace(3, "transform") << "-- check arguments" << end();
4432 Good idea from @tekknolagi: make more explicit that the first segment is code.
2018-07-27 06:26:20 +00:00
for (int i = 0; i < SIZE(code.lines); ++i) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments(code.lines.at(i));
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
if (trace_contains_errors()) return; // stop at the first mal-formed instruction
}
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments(const line& inst) {
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
word op = preprocess_op(inst.words.at(0));
if (op.data == "0f") {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_0f(inst);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
return;
}
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
if (op.data == "f3") {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_f3(inst);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
return;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments(inst, op);
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
}
word preprocess_op(word/*copy*/ op) {
op.data = tolower(op.data.c_str());
4503
2018-08-11 17:33:26 +00:00
// opcodes can't be negative
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
if (starts_with(op.data, "0x"))
op.data = op.data.substr(2);
4503
2018-08-11 17:33:26 +00:00
if (SIZE(op.data) == 1)
op.data = string("0")+op.data;
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
return op;
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
4503
2018-08-11 17:33:26 +00:00
void test_preprocess_op() {
word w1; w1.data = "0xf";
word w2; w2.data = "0f";
CHECK_EQ(preprocess_op(w1).data, preprocess_op(w2).data);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
//: To check the arguments for an opcode, we'll track the permitted arguments
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//: for each supported opcode in a bitvector. That way we can often compute the
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
//: 'received' argument bitvector for each instruction's arguments and compare
4882
2018-12-28 18:29:19 +00:00
//: it with the 'expected' bitvector.
//:
//: The 'expected' and 'received' bitvectors can be different; the MODRM bit
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
//: in the 'expected' bitvector maps to multiple 'received' argument types in
4882
2018-12-28 18:29:19 +00:00
//: an instruction. We deal in expected bitvectors throughout.
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(before "End Types")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
enum expected_argument_type {
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// start from the least significant bit
MODRM, // more complex, may also involve disp8 or disp32
SUBOP,
DISP8,
DISP16,
DISP32,
IMM8,
IMM32,
NUM_OPERAND_TYPES
};
:(before "End Globals")
vector<string> Operand_type_name;
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
map<string, expected_argument_type> Operand_type;
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(before "End One-time Setup")
init_op_types();
:(code)
void init_op_types() {
assert(NUM_OPERAND_TYPES <= /*bits in a uint8_t*/8);
Operand_type_name.resize(NUM_OPERAND_TYPES);
#define DEF(type) Operand_type_name.at(type) = tolower(#type), put(Operand_type, tolower(#type), type);
DEF(MODRM);
DEF(SUBOP);
DEF(DISP8);
DEF(DISP16);
DEF(DISP32);
DEF(IMM8);
DEF(IMM32);
#undef DEF
}
:(before "End Globals")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
map</*op*/string, /*bitvector*/uint8_t> Permitted_arguments;
const uint8_t INVALID_OPERANDS = 0xff; // no instruction uses all the argument types
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(before "End One-time Setup")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
init_permitted_arguments();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(code)
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void init_permitted_arguments() {
//// Class A: just op, no arguments
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// halt
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "f4", 0x00);
4578 - subx: implement inc/dec operations
2018-09-21 23:02:50 +00:00
// inc
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "40", 0x00);
put(Permitted_arguments, "41", 0x00);
put(Permitted_arguments, "42", 0x00);
put(Permitted_arguments, "43", 0x00);
put(Permitted_arguments, "44", 0x00);
put(Permitted_arguments, "45", 0x00);
put(Permitted_arguments, "46", 0x00);
put(Permitted_arguments, "47", 0x00);
4578 - subx: implement inc/dec operations
2018-09-21 23:02:50 +00:00
// dec
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "48", 0x00);
put(Permitted_arguments, "49", 0x00);
put(Permitted_arguments, "4a", 0x00);
put(Permitted_arguments, "4b", 0x00);
put(Permitted_arguments, "4c", 0x00);
put(Permitted_arguments, "4d", 0x00);
put(Permitted_arguments, "4e", 0x00);
put(Permitted_arguments, "4f", 0x00);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// push
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "50", 0x00);
put(Permitted_arguments, "51", 0x00);
put(Permitted_arguments, "52", 0x00);
put(Permitted_arguments, "53", 0x00);
put(Permitted_arguments, "54", 0x00);
put(Permitted_arguments, "55", 0x00);
put(Permitted_arguments, "56", 0x00);
put(Permitted_arguments, "57", 0x00);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// pop
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "58", 0x00);
put(Permitted_arguments, "59", 0x00);
put(Permitted_arguments, "5a", 0x00);
put(Permitted_arguments, "5b", 0x00);
put(Permitted_arguments, "5c", 0x00);
put(Permitted_arguments, "5d", 0x00);
put(Permitted_arguments, "5e", 0x00);
put(Permitted_arguments, "5f", 0x00);
5114 - helper for idiv instruction
2019-04-22 06:48:39 +00:00
// sign-extend EAX into EDX
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "99", 0x00);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// return
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "c3", 0x00);
some hacky checks for common errors They're not really baked into the regular compilation process; I have to remember to run them if I see strange behavior.
2021-04-01 06:16:01 +00:00
// enable/disable interrupts
// not really part of SubX; just needed in low-level boot.subx
put(Permitted_arguments, "fa", 0x00);
put(Permitted_arguments, "fb", 0x00);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//// Class B: just op and disp8
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 0 |0 1 0 0
// jump
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "eb", 0x04);
put(Permitted_arguments, "72", 0x04);
put(Permitted_arguments, "73", 0x04);
put(Permitted_arguments, "74", 0x04);
put(Permitted_arguments, "75", 0x04);
put(Permitted_arguments, "76", 0x04);
put(Permitted_arguments, "77", 0x04);
put(Permitted_arguments, "7c", 0x04);
put(Permitted_arguments, "7d", 0x04);
put(Permitted_arguments, "7e", 0x04);
put(Permitted_arguments, "7f", 0x04);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//// Class D: just op and disp32
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 1 |0 0 0 0
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "e8", 0x10); // call
put(Permitted_arguments, "e9", 0x10); // jump
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//// Class E: just op and imm8
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 1 0 |0 0 0 0
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "cd", 0x20); // software interrupt
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//// Class F: just op and imm32
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 1 0 0 |0 0 0 0
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "05", 0x40); // add
put(Permitted_arguments, "2d", 0x40); // subtract
put(Permitted_arguments, "25", 0x40); // and
put(Permitted_arguments, "0d", 0x40); // or
put(Permitted_arguments, "35", 0x40); // xor
put(Permitted_arguments, "3d", 0x40); // compare
put(Permitted_arguments, "68", 0x40); // push
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// copy
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "b8", 0x40);
put(Permitted_arguments, "b9", 0x40);
put(Permitted_arguments, "ba", 0x40);
put(Permitted_arguments, "bb", 0x40);
put(Permitted_arguments, "bc", 0x40);
put(Permitted_arguments, "bd", 0x40);
put(Permitted_arguments, "be", 0x40);
put(Permitted_arguments, "bf", 0x40);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//// Class M: using ModR/M byte
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 0 |0 0 0 1
// add
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "01", 0x01);
put(Permitted_arguments, "03", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// subtract
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "29", 0x01);
put(Permitted_arguments, "2b", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// and
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "21", 0x01);
put(Permitted_arguments, "23", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// or
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "09", 0x01);
put(Permitted_arguments, "0b", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// xor
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "31", 0x01);
put(Permitted_arguments, "33", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// compare
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "39", 0x01);
put(Permitted_arguments, "3b", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// copy
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "88", 0x01);
put(Permitted_arguments, "89", 0x01);
put(Permitted_arguments, "8a", 0x01);
put(Permitted_arguments, "8b", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// swap
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "87", 0x01);
4718
2018-10-24 22:52:41 +00:00
// copy address (lea)
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "8d", 0x01);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
4830 New helper: printing a byte in textual (hex) form. This required adding instructions for bitwise shift operations.
2018-12-04 07:26:56 +00:00
//// Class N: op, ModR/M and subop (not r32)
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 0 |0 0 1 1
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "8f", 0x03); // pop
put(Permitted_arguments, "d3", 0x03); // shift
put(Permitted_arguments, "f7", 0x03); // test/not/mul/div
put(Permitted_arguments, "ff", 0x03); // jump/push/call
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
4830 New helper: printing a byte in textual (hex) form. This required adding instructions for bitwise shift operations.
2018-12-04 07:26:56 +00:00
//// Class O: op, ModR/M, subop (not r32) and imm8
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 1 0 |0 0 1 1
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "c1", 0x23); // combine
put(Permitted_arguments, "c6", 0x23); // copy
4830 New helper: printing a byte in textual (hex) form. This required adding instructions for bitwise shift operations.
2018-12-04 07:26:56 +00:00
4886
2018-12-29 05:26:42 +00:00
//// Class P: op, ModR/M, subop (not r32) and imm32
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 1 0 0 |0 0 1 1
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "81", 0x43); // combine
put(Permitted_arguments, "c7", 0x43); // copy
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
6090 - new instruction: multiply by immediate This is a 3-operand instruction: r32 = rm32 * imm32 It looks like https://c9x.me/x86/html/file_module_x86_id_138.html has a bug, implying the same opcode supports a 2-operand version. I don't see that in the Intel manual pdf, or at alternative sites like https://www.felixcloutier.com/x86/imul Native runs seem to validate my understanding. In the process I also fixed a bug in the existing multiply instruction 0f af: the only flags it sets are OF and CF. The other existing multiply instruction f7 was doing things right.
2020-03-07 02:31:14 +00:00
//// Class Q: op, ModR/M and imm32
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 1 0 0 |0 0 0 1
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put(Permitted_arguments, "69", 0x41); // multiply
6090 - new instruction: multiply by immediate This is a 3-operand instruction: r32 = rm32 * imm32 It looks like https://c9x.me/x86/html/file_module_x86_id_138.html has a bug, implying the same opcode supports a 2-operand version. I don't see that in the Intel manual pdf, or at alternative sites like https://www.felixcloutier.com/x86/imul Native runs seem to validate my understanding. In the process I also fixed a bug in the existing multiply instruction 0f af: the only flags it sets are OF and CF. The other existing multiply instruction f7 was doing things right.
2020-03-07 02:31:14 +00:00
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
// End Init Permitted Operands
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
#define HAS(bitvector, bit) ((bitvector) & (1 << (bit)))
#define SET(bitvector, bit) ((bitvector) | (1 << (bit)))
#define CLEAR(bitvector, bit) ((bitvector) & (~(1 << (bit))))
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments(const line& inst, const word& op) {
4437 - support for labels is half-done
2018-07-27 17:58:15 +00:00
if (!is_hex_byte(op)) return;
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
uint8_t expected_bitvector = get(Permitted_arguments, op.data);
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
if (HAS(expected_bitvector, MODRM)) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_modrm(inst, op);
5956
2020-01-30 07:57:45 +00:00
compare_bitvector_modrm(inst, expected_bitvector, maybe_name(op));
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
}
else {
5956
2020-01-30 07:57:45 +00:00
compare_bitvector(inst, expected_bitvector, maybe_name(op));
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
//: Many instructions can be checked just by comparing bitvectors.
5956
2020-01-30 07:57:45 +00:00
void compare_bitvector(const line& inst, uint8_t expected, const string& maybe_op_name) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if (all_hex_bytes(inst) && has_arguments(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
uint8_t bitvector = compute_expected_argument_bitvector(inst);
if (trace_contains_errors()) return; // duplicate argument type
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
if (bitvector == expected) return; // all good with this instruction
for (int i = 0; i < NUM_OPERAND_TYPES; ++i, bitvector >>= 1, expected >>= 1) {
//? cerr << "comparing " << HEXBYTE << NUM(bitvector) << " with " << NUM(expected) << '\n';
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if ((bitvector & 0x1) == (expected & 0x1)) continue; // all good with this argument
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
const string& optype = Operand_type_name.at(i);
if ((bitvector & 0x1) > (expected & 0x1))
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
raise << "'" << to_string(inst) << "'" << maybe_op_name << ": unexpected " << optype << " argument\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
else
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
raise << "'" << to_string(inst) << "'" << maybe_op_name << ": missing " << optype << " argument\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// continue giving all errors for a single instruction
}
// ignore settings in any unused bits
}
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
string maybe_name(const word& op) {
if (!is_hex_byte(op)) return "";
4695
2018-10-14 07:00:39 +00:00
if (!contains_key(Name, op.data)) return "";
4697
2018-10-14 07:29:48 +00:00
// strip stuff in parens from the name
const string& s = get(Name, op.data);
return " ("+s.substr(0, s.find(" ("))+')';
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
uint32_t compute_expected_argument_bitvector(const line& inst) {
set<string> arguments_found;
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
uint32_t bitvector = 0;
for (int i = /*skip op*/1; i < SIZE(inst.words); ++i) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
bitvector = bitvector | expected_bit_for_received_argument(inst.words.at(i), arguments_found, inst);
if (trace_contains_errors()) return INVALID_OPERANDS; // duplicate argument type
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
return bitvector;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
bool has_arguments(const line& inst) {
return SIZE(inst.words) > first_argument(inst);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
int first_argument(const line& inst) {
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
if (inst.words.at(0).data == "0f") return 2;
4501
2018-08-11 17:22:51 +00:00
if (inst.words.at(0).data == "f2" || inst.words.at(0).data == "f3") {
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
if (inst.words.at(1).data == "0f")
return 3;
else
return 2;
}
return 1;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
// Scan the metadata of 'w' and return the expected bit corresponding to any argument type.
// Also raise an error if metadata contains multiple argument types.
uint32_t expected_bit_for_received_argument(const word& w, set<string>& instruction_arguments, const line& inst) {
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
uint32_t bv = 0;
bool found = false;
for (int i = 0; i < SIZE(w.metadata); ++i) {
4882
2018-12-28 18:29:19 +00:00
string/*copy*/ curr = w.metadata.at(i);
4941
2019-01-21 08:58:45 +00:00
string expected_metadata = curr;
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
if (curr == "mod" || curr == "rm32" || curr == "r32" || curr == "xm32" || curr == "x32" || curr == "scale" || curr == "index" || curr == "base")
4941
2019-01-21 08:58:45 +00:00
expected_metadata = "modrm";
4882
2018-12-28 18:29:19 +00:00
else if (!contains_key(Operand_type, curr)) continue; // ignore unrecognized metadata
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
if (found) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
raise << "'" << w.original << "' has conflicting argument types; it should have only one\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
return INVALID_OPERANDS;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if (instruction_arguments.find(curr) != instruction_arguments.end()) {
raise << "'" << to_string(inst) << "': duplicate " << curr << " argument\n" << end();
4941
2019-01-21 08:58:45 +00:00
return INVALID_OPERANDS;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
instruction_arguments.insert(curr);
4941
2019-01-21 08:58:45 +00:00
bv = (1 << get(Operand_type, expected_metadata));
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
found = true;
}
return bv;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_conflicting_argument_type() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"cd/software-interrupt 80/imm8/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '80/imm8/imm32' has conflicting argument types; it should have only one\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//: Instructions computing effective addresses have more complex rules, so
//: we'll hard-code a common set of instruction-decoding rules.
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_mod_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 3/rm32/ebx 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '81 0/add/subop 3/rm32/ebx 1/imm32' (combine rm32 with imm32 based on subop): missing mod argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_modrm(const line& inst, const word& op) {
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
if (all_hex_bytes(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_argument_metadata_present(inst, "mod", op);
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
if (!has_argument_metadata(inst, "rm32") && !has_argument_metadata(inst, "xm32"))
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": missing rm32 (or xm32) argument\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// no check for r32; some instructions don't use it; just assume it's 0 if missing
6727 - bugfix in a multiply instruction Also more error-detection for this case all across the toolchain.
2020-08-22 21:35:44 +00:00
if (op.data == "81" || op.data == "8f" || op.data == "f7" || op.data == "ff") { // keep sync'd with 'help subop'
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_argument_metadata_present(inst, "subop", op);
check_argument_metadata_absent(inst, "r32", op, "should be replaced by subop");
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
check_argument_metadata_absent(inst, "x32", op, "should be replaced by subop");
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
if (trace_contains_errors()) return;
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
if (metadata_m32(inst).data != "4") return;
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
// SIB byte checks
uint8_t mod = hex_byte(metadata(inst, "mod").data);
if (mod != /*direct*/3) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_argument_metadata_present(inst, "base", op);
check_argument_metadata_present(inst, "index", op); // otherwise why go to SIB?
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
else {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_argument_metadata_absent(inst, "base", op, "direct mode");
check_argument_metadata_absent(inst, "index", op, "direct mode");
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
// no check for scale; 0 (2**0 = 1) by default
}
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
word metadata_m32(const line& inst) {
for (int i = 0; i < SIZE(inst.words); ++i)
if (has_argument_metadata(inst.words.at(i), "rm32") || has_argument_metadata(inst.words.at(i), "xm32"))
return inst.words.at(i);
assert(false);
}
4909 Improve error checking to warn on unexpected displacements as well.
2019-01-05 21:02:42 +00:00
// same as compare_bitvector, with one additional exception for modrm-based
// instructions: they may use an extra displacement on occasion
5956
2020-01-30 07:57:45 +00:00
void compare_bitvector_modrm(const line& inst, uint8_t expected, const string& maybe_op_name) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if (all_hex_bytes(inst) && has_arguments(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
uint8_t bitvector = compute_expected_argument_bitvector(inst);
if (trace_contains_errors()) return; // duplicate argument type
4909 Improve error checking to warn on unexpected displacements as well.
2019-01-05 21:02:42 +00:00
// update 'expected' bitvector for the additional exception
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if (has_argument_metadata(inst, "mod")) {
4909 Improve error checking to warn on unexpected displacements as well.
2019-01-05 21:02:42 +00:00
int32_t mod = parse_int(metadata(inst, "mod").data);
switch (mod) {
case 0:
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if (has_argument_metadata(inst, "rm32") && parse_int(metadata(inst, "rm32").data) == 5)
4909 Improve error checking to warn on unexpected displacements as well.
2019-01-05 21:02:42 +00:00
expected |= (1<<DISP32);
break;
case 1:
expected |= (1<<DISP8);
break;
case 2:
expected |= (1<<DISP32);
break;
}
}
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
if (bitvector == expected) return; // all good with this instruction
for (int i = 0; i < NUM_OPERAND_TYPES; ++i, bitvector >>= 1, expected >>= 1) {
//? cerr << "comparing for modrm " << HEXBYTE << NUM(bitvector) << " with " << NUM(expected) << '\n';
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
if ((bitvector & 0x1) == (expected & 0x1)) continue; // all good with this argument
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
const string& optype = Operand_type_name.at(i);
if ((bitvector & 0x1) > (expected & 0x1))
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
raise << "'" << to_string(inst) << "'" << maybe_op_name << ": unexpected " << optype << " argument\n" << end();
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
else
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
raise << "'" << to_string(inst) << "'" << maybe_op_name << ": missing " << optype << " argument\n" << end();
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
// continue giving all errors for a single instruction
}
// ignore settings in any unused bits
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_argument_metadata_present(const line& inst, const string& type, const word& op) {
if (!has_argument_metadata(inst, type))
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": missing " << type << " argument\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_argument_metadata_absent(const line& inst, const string& type, const word& op, const string& msg) {
if (has_argument_metadata(inst, type))
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": unexpected " << type << " argument (" << msg << ")\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
void test_modrm_with_displacement() {
Reg[EAX].u = 0x1;
transform(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
// just avoid null pointer
"8b/copy 1/mod/lookup+disp8 0/rm32/EAX 2/r32/EDX 4/disp8\n" // copy *(EAX+4) to EDX
);
CHECK_TRACE_COUNT("error", 0);
}
void test_check_missing_disp8() {
Hide_errors = true;
transform(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"89/copy 1/mod/lookup+disp8 0/rm32/EAX 1/r32/ECX\n" // missing disp8
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '89/copy 1/mod/lookup+disp8 0/rm32/EAX 1/r32/ECX' (copy r32 to rm32): missing disp8 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
void test_check_missing_disp32() {
Hide_errors = true;
transform(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"8b/copy 0/mod/indirect 5/rm32/.disp32 2/r32/EDX\n" // missing disp32
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '8b/copy 0/mod/indirect 5/rm32/.disp32 2/r32/EDX' (copy rm32 to r32): missing disp32 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_conflicting_arguments_in_modrm_instruction() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"01/add 0/mod 3/mod\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '01/add 0/mod 3/mod' has conflicting mod arguments\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_conflicting_argument_type_modrm() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"01/add 0/mod 3/rm32/r32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '3/rm32/r32' has conflicting argument types; it should have only one\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_rm32_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 0/mod 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6888 Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-28 05:41:55 +00:00
"error: '81 0/add/subop 0/mod 1/imm32' (combine rm32 with imm32 based on subop): missing rm32 (or xm32) argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_subop_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/mod 3/rm32/ebx 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '81 0/mod 3/rm32/ebx 1/imm32' (combine rm32 with imm32 based on subop): missing subop argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_base_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 0/mod/indirect 4/rm32/use-sib 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '81 0/add/subop 0/mod/indirect 4/rm32/use-sib 1/imm32' (combine rm32 with imm32 based on subop): missing base argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_index_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 0/mod/indirect 4/rm32/use-sib 0/base 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '81 0/add/subop 0/mod/indirect 4/rm32/use-sib 0/base 1/imm32' (combine rm32 with imm32 based on subop): missing index argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_base_argument_2() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 0/mod/indirect 4/rm32/use-sib 2/index 3/scale 1/imm32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '81 0/add/subop 0/mod/indirect 4/rm32/use-sib 2/index 3/scale 1/imm32' (combine rm32 with imm32 based on subop): missing base argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
void test_check_extra_displacement() {
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 4/disp8\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 4/disp8' (copy r32 to rm32): unexpected disp8 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_duplicate_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 1/r32\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 1/r32': duplicate r32 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_base_argument_not_needed_in_direct_mode() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"81 0/add/subop 3/mod/indirect 4/rm32/use-sib 1/imm32\n"
);
CHECK_TRACE_COUNT("error", 0);
}
void test_extra_modrm() {
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
"59/pop-to-ECX 3/mod/direct 1/rm32/ECX 4/r32/ESP\n"
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '59/pop-to-ECX 3/mod/direct 1/rm32/ECX 4/r32/ESP' (pop top of stack to ECX): unexpected modrm argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
4882
2018-12-28 18:29:19 +00:00
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
//:: similarly handle multi-byte opcodes
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_0f(const line& inst) {
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
assert(inst.words.at(0).data == "0f");
if (SIZE(inst.words) == 1) {
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
raise << "opcode '0f' requires a second opcode\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
return;
}
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
word op = preprocess_op(inst.words.at(1));
4695
2018-10-14 07:00:39 +00:00
if (!contains_key(Name_0f, op.data)) {
4434 Key core data structures by hex bytes in text rather than opcode numbers. Saves us round trips of having to parse and reparse strings, and also allows us to more easily ignore unexpected non-hex words in each transform. We'll use this ability next when we start inserting labels.
2018-07-27 17:15:03 +00:00
raise << "unknown 2-byte opcode '0f " << op.data << "'\n" << end();
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
return;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_0f(inst, op);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_f3(const line& inst) {
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
assert(inst.words.at(0).data == "f3");
if (SIZE(inst.words) == 1) {
raise << "opcode 'f3' requires a second opcode\n" << end();
return;
}
word op = preprocess_op(inst.words.at(1));
if (op.data == "0f") {
word op2 = preprocess_op(inst.words.at(2));
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_f3_0f(inst, op2);
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
return;
}
if (!contains_key(Name_f3, op.data)) {
raise << "unknown 2-byte opcode 'f3 " << op.data << "'\n" << end();
return;
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_f3(inst, op);
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void test_check_missing_disp32_argument() {
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
Hide_errors = true;
run(
switch to new syntax for segment headers in C++
2019-05-18 07:00:18 +00:00
"== code 0x1\n"
" 0f 84 # jmp if ZF to ??\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
CHECK_TRACE_CONTENTS(
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
"error: '0f 84' (jump disp32 bytes away if equal, if ZF is set): missing disp32 argument\n"
5001 - drop the :(scenario) DSL I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
2019-03-13 01:56:55 +00:00
);
}
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
5957 - bootstrap: stale checks for 2-byte opcodes
2020-01-30 08:02:53 +00:00
void test_0f_opcode_with_modrm() {
transform(
"== code 0x1\n"
"0f af/multiply 2/mod/*+disp32 5/rm32/ebp 8/disp32 0/r32\n"
);
CHECK_TRACE_DOESNT_CONTAIN_ERRORS();
}
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
:(before "End Globals")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
map</*op*/string, /*bitvector*/uint8_t> Permitted_arguments_0f;
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
:(before "End Init Permitted Operands")
4776 Crenshaw compiler now runs natively as well. It turns out I was misreading the Intel manual, and the jump instructions that I thought take disp16 operands actually take disp32 operands by default on both i686 and x86_64 processors. The disp16 versions are some holdover from the 16-bit days. This was the first time I've used one of these erstwhile-disp16 instructions, but I still haven't tested most of them. We'll see if we run into future issues.
2018-11-25 21:46:53 +00:00
//// Class D: just op and disp32
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
// imm32 imm8 disp32 |disp16 disp8 subop modrm
4776 Crenshaw compiler now runs natively as well. It turns out I was misreading the Intel manual, and the jump instructions that I thought take disp16 operands actually take disp32 operands by default on both i686 and x86_64 processors. The disp16 versions are some holdover from the 16-bit days. This was the first time I've used one of these erstwhile-disp16 instructions, but I still haven't tested most of them. We'll see if we run into future issues.
2018-11-25 21:46:53 +00:00
// 0 0 1 |0 0 0 0
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put_new(Permitted_arguments_0f, "82", 0x10);
put_new(Permitted_arguments_0f, "83", 0x10);
put_new(Permitted_arguments_0f, "84", 0x10);
put_new(Permitted_arguments_0f, "85", 0x10);
put_new(Permitted_arguments_0f, "86", 0x10);
put_new(Permitted_arguments_0f, "87", 0x10);
put_new(Permitted_arguments_0f, "8c", 0x10);
put_new(Permitted_arguments_0f, "8d", 0x10);
put_new(Permitted_arguments_0f, "8e", 0x10);
put_new(Permitted_arguments_0f, "8f", 0x10);
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
4450
2018-07-30 16:56:53 +00:00
//// Class M: using ModR/M byte
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 0 |0 0 0 1
6911 - comparing floats It turns out floating-point operations set different flags than most instructions. We have to branch on them using unsigned jumps. https://stackoverflow.com/questions/7057501/x86-assembler-floating-point-compare/7057771#7057771
2020-10-01 05:50:26 +00:00
put_new(Permitted_arguments_0f, "2f", 0x01); // compare floats
put_new(Permitted_arguments_0f, "af", 0x01); // multiply ints
6088 - start using setCC instructions
2020-03-07 01:41:36 +00:00
// setcc
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
put_new(Permitted_arguments_0f, "92", 0x01);
put_new(Permitted_arguments_0f, "93", 0x01);
put_new(Permitted_arguments_0f, "94", 0x01);
put_new(Permitted_arguments_0f, "95", 0x01);
put_new(Permitted_arguments_0f, "96", 0x01);
put_new(Permitted_arguments_0f, "97", 0x01);
put_new(Permitted_arguments_0f, "9c", 0x01);
put_new(Permitted_arguments_0f, "9d", 0x01);
put_new(Permitted_arguments_0f, "9e", 0x01);
put_new(Permitted_arguments_0f, "9f", 0x01);
4450
2018-07-30 16:56:53 +00:00
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
:(before "End Globals")
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
map</*op*/string, /*bitvector*/uint8_t> Permitted_arguments_f3;
map</*op*/string, /*bitvector*/uint8_t> Permitted_arguments_f3_0f;
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
:(before "End Init Permitted Operands")
//// Class M: using ModR/M byte
// imm32 imm8 disp32 |disp16 disp8 subop modrm
// 0 0 0 |0 0 0 1
6913 - copying floats around
2020-10-01 06:12:39 +00:00
put_new(Permitted_arguments_f3_0f, "10", 0x01); // copy xm32 to x32
put_new(Permitted_arguments_f3_0f, "11", 0x01); // copy x32 to xm32
6910 - emulate most floating-point operations
2020-10-01 05:07:38 +00:00
put_new(Permitted_arguments_f3_0f, "2a", 0x01); // convert-to-float
6957 The final fix to the raytracing program involves rounding modes. It turns out x86 processors round floats by default, unlike C which has trained me to expect truncation. Rather than mess with the MXCSR register, I added another instruction for truncation. Now milestone 3 emits perfectly correct results.
2020-10-05 17:16:53 +00:00
put_new(Permitted_arguments_f3_0f, "2c", 0x01); // truncate-to-int
6910 - emulate most floating-point operations
2020-10-01 05:07:38 +00:00
put_new(Permitted_arguments_f3_0f, "2d", 0x01); // convert-to-int
put_new(Permitted_arguments_f3_0f, "51", 0x01); // square root
put_new(Permitted_arguments_f3_0f, "52", 0x01); // inverse square root
put_new(Permitted_arguments_f3_0f, "53", 0x01); // reciprocal
put_new(Permitted_arguments_f3_0f, "58", 0x01); // add floats
put_new(Permitted_arguments_f3_0f, "59", 0x01); // multiply floats
put_new(Permitted_arguments_f3_0f, "5c", 0x01); // subtract floats
put_new(Permitted_arguments_f3_0f, "5d", 0x01); // minimum of floats
put_new(Permitted_arguments_f3_0f, "5e", 0x01); // divide floats
put_new(Permitted_arguments_f3_0f, "5f", 0x01); // maximum of floats
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
4429 - syntax checking for multi-byte opcodes We don't have any supported 3-byte opcodes at the moment.
2018-07-27 03:17:08 +00:00
:(code)
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_0f(const line& inst, const word& op) {
uint8_t expected_bitvector = get(Permitted_arguments_0f, op.data);
5957 - bootstrap: stale checks for 2-byte opcodes
2020-01-30 08:02:53 +00:00
if (HAS(expected_bitvector, MODRM)) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_modrm(inst, op);
5957 - bootstrap: stale checks for 2-byte opcodes
2020-01-30 08:02:53 +00:00
compare_bitvector_modrm(inst, expected_bitvector, maybe_name_0f(op));
}
else {
compare_bitvector(inst, CLEAR(expected_bitvector, MODRM), maybe_name_0f(op));
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_f3(const line& inst, const word& op) {
uint8_t expected_bitvector = get(Permitted_arguments_f3, op.data);
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
if (HAS(expected_bitvector, MODRM)) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_modrm(inst, op);
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
compare_bitvector_modrm(inst, expected_bitvector, maybe_name_f3(op));
}
else {
compare_bitvector(inst, CLEAR(expected_bitvector, MODRM), maybe_name_f3(op));
}
}
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
void check_arguments_f3_0f(const line& inst, const word& op) {
uint8_t expected_bitvector = get(Permitted_arguments_f3_0f, op.data);
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
if (HAS(expected_bitvector, MODRM)) {
6887 subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
2020-09-28 05:05:11 +00:00
check_arguments_modrm(inst, op);
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
compare_bitvector_modrm(inst, expected_bitvector, maybe_name_f3_0f(op));
}
else {
compare_bitvector(inst, CLEAR(expected_bitvector, MODRM), maybe_name_f3_0f(op));
}
}
4697
2018-10-14 07:29:48 +00:00
string maybe_name_0f(const word& op) {
if (!is_hex_byte(op)) return "";
if (!contains_key(Name_0f, op.data)) return "";
// strip stuff in parens from the name
const string& s = get(Name_0f, op.data);
return " ("+s.substr(0, s.find(" ("))+')';
}
6885 - starting on floating-point instructions I spent some time deciding on the instructions. x87 is a stack ISA, so not a good fit for the rest of SubX. So we use SSE instead. They operate on 32-bit floats, which seems like a good fit. SSE has a bunch of instructions for operating on up to 4 floats at once. We'll ignore all that and just focus on so-called scalar instructions.
2020-09-28 04:12:48 +00:00
string maybe_name_f3(const word& op) {
if (!is_hex_byte(op)) return "";
if (!contains_key(Name_f3, op.data)) return "";
// strip stuff in parens from the name
const string& s = get(Name_f3, op.data);
return " ("+s.substr(0, s.find(" ("))+')';
}
string maybe_name_f3_0f(const word& op) {
if (!is_hex_byte(op)) return "";
if (!contains_key(Name_f3_0f, op.data)) return "";
// strip stuff in parens from the name
const string& s = get(Name_f3_0f, op.data);
return " ("+s.substr(0, s.find(" ("))+')';
}
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
string tolower(const char* s) {
ostringstream out;
for (/*nada*/; *s; ++s)
out << static_cast<char>(tolower(*s));
return out.str();
}
4452 Keep a few macros more tightly scoped to just the transform they're used in.
2018-07-30 16:58:13 +00:00
#undef HAS
#undef SET
#undef CLEAR
4414 - subx: syntax checking This is a large patch, and there's a few things wrong with it: a) Helpers are incredibly messy. I want to use has_metadata in layer 24, but can't since it also does error checking. There must be a better basis set of primitives for managing metadata. b) Layer 22 introduces operands for checking, but programs with operands don't actually run until layer 24. So I can't write non-error scenarios in layer 22. That seems ugly. But if I try to introduce layer 24 first there's nothing left to check after it. I *could* play tricks with ordering layers vs transforms. Mu does that a bit, but it becomes hard to mess with, so I'm trying to avoid that. My current plan is for layers within an "abstraction level" to be run in order. Higher layers will necessarily need to come before lower ones. But hopefully this level of hierarchy will help manage the chaos. c) The check for whether an instruction is all hex bytes makes me nervous. I do want to check that an instruction that's just: cd tells the programmer that an operand is missing. The check I currently have is likely not perfectly correct. I *could* put layer 25 in its own commit. But I guess I'm not doing that now. We have a new example program: hello world!
2018-07-26 03:53:43 +00:00
:(before "End Includes")
#include<cctype>