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

692 lines
23 KiB
C++
Raw Normal View History

4483 Reorganize layers in accordance with the plan in layer 29.
2018-08-05 05:59:47 +00:00
//: Since we're tagging operands with their types, let's start checking these
//: operand 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
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_imm8_operand() {
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(
"error: 'cd' (software interrupt): missing imm8 operand\n"
);
}
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)")
4483 Reorganize layers in accordance with the plan in layer 29.
2018-08-05 05:59:47 +00:00
check_operands(code);
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)
4483 Reorganize layers in accordance with the plan in layer 29.
2018-08-05 05:59:47 +00:00
void check_operands(const segment& code) {
4987 - support `browse_trace` tool in SubX I've extracted it into a separate binary, independent of my Mu prototype. I also cleaned up my tracing layer to be a little nicer. Major improvements: - Realized that incremental tracing really ought to be the default. And to minimize printing traces to screen. - Finally figured out how to combine layers and call stack frames in a single dimension of depth. The answer: optimize for the experience of `browse_trace`. Instructions occupy a range of depths based on their call stack frame, and minor details of an instruction lie one level deeper in each case. Other than that, I spent some time adjusting levels everywhere to make `browse_trace` useful.
2019-02-25 08:17:46 +00:00
trace(3, "transform") << "-- check operands" << 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) {
check_operands(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
}
}
void check_operands(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") {
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
check_operands_0f(inst);
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") {
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
check_operands_f3(inst);
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
check_operands(inst, op);
}
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);
}
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
//: To check the operands for an opcode, we'll track the permitted operands
//: for each supported opcode in a bitvector. That way we can often compute the
4882
2018-12-28 18:29:19 +00:00
//: 'received' operand bitvector for each instruction's operands and compare
//: it with the 'expected' bitvector.
//:
//: The 'expected' and 'received' bitvectors can be different; the MODRM bit
//: in the 'expected' bitvector maps to multiple 'received' operand types in
//: 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")
4882
2018-12-28 18:29:19 +00:00
enum expected_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
// 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;
4882
2018-12-28 18:29:19 +00:00
map<string, expected_operand_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")
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
map</*op*/string, /*bitvector*/uint8_t> Permitted_operands;
const uint8_t INVALID_OPERANDS = 0xff; // no instruction uses all the operand 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")
init_permitted_operands();
:(code)
void init_permitted_operands() {
//// Class A: just op, no operands
// halt
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
put(Permitted_operands, "f4", 0x00);
4578 - subx: implement inc/dec operations
2018-09-21 23:02:50 +00:00
// inc
put(Permitted_operands, "40", 0x00);
put(Permitted_operands, "41", 0x00);
put(Permitted_operands, "42", 0x00);
put(Permitted_operands, "43", 0x00);
put(Permitted_operands, "44", 0x00);
put(Permitted_operands, "45", 0x00);
put(Permitted_operands, "46", 0x00);
put(Permitted_operands, "47", 0x00);
// dec
put(Permitted_operands, "48", 0x00);
put(Permitted_operands, "49", 0x00);
put(Permitted_operands, "4a", 0x00);
put(Permitted_operands, "4b", 0x00);
put(Permitted_operands, "4c", 0x00);
put(Permitted_operands, "4d", 0x00);
put(Permitted_operands, "4e", 0x00);
put(Permitted_operands, "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
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
put(Permitted_operands, "50", 0x00);
put(Permitted_operands, "51", 0x00);
put(Permitted_operands, "52", 0x00);
put(Permitted_operands, "53", 0x00);
put(Permitted_operands, "54", 0x00);
put(Permitted_operands, "55", 0x00);
put(Permitted_operands, "56", 0x00);
put(Permitted_operands, "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
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
put(Permitted_operands, "58", 0x00);
put(Permitted_operands, "59", 0x00);
put(Permitted_operands, "5a", 0x00);
put(Permitted_operands, "5b", 0x00);
put(Permitted_operands, "5c", 0x00);
put(Permitted_operands, "5d", 0x00);
put(Permitted_operands, "5e", 0x00);
put(Permitted_operands, "5f", 0x00);
5114 - helper for idiv instruction
2019-04-22 06:48:39 +00:00
// sign-extend EAX into EDX
put(Permitted_operands, "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
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
put(Permitted_operands, "c3", 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
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
put(Permitted_operands, "eb", 0x04);
start using the new carry flag Skimping on tests; the code changes seem pretty trivial. Will this fix CI?!
2019-05-14 00:27:45 +00:00
put(Permitted_operands, "72", 0x04);
put(Permitted_operands, "73", 0x04);
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
put(Permitted_operands, "74", 0x04);
put(Permitted_operands, "75", 0x04);
start using the new carry flag Skimping on tests; the code changes seem pretty trivial. Will this fix CI?!
2019-05-14 00:27:45 +00:00
put(Permitted_operands, "76", 0x04);
put(Permitted_operands, "77", 0x04);
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
put(Permitted_operands, "7c", 0x04);
put(Permitted_operands, "7d", 0x04);
put(Permitted_operands, "7e", 0x04);
put(Permitted_operands, "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
4453 Got a couple of instructions mixed up.
2018-07-30 16:58:59 +00:00
put(Permitted_operands, "e8", 0x10); // call
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
put(Permitted_operands, "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
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
put(Permitted_operands, "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
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
put(Permitted_operands, "05", 0x40); // add
put(Permitted_operands, "2d", 0x40); // subtract
put(Permitted_operands, "25", 0x40); // and
put(Permitted_operands, "0d", 0x40); // or
put(Permitted_operands, "35", 0x40); // xor
put(Permitted_operands, "3d", 0x40); // compare
put(Permitted_operands, "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
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
put(Permitted_operands, "b8", 0x40);
put(Permitted_operands, "b9", 0x40);
put(Permitted_operands, "ba", 0x40);
put(Permitted_operands, "bb", 0x40);
put(Permitted_operands, "bc", 0x40);
put(Permitted_operands, "bd", 0x40);
put(Permitted_operands, "be", 0x40);
put(Permitted_operands, "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
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
put(Permitted_operands, "01", 0x01);
put(Permitted_operands, "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
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
put(Permitted_operands, "29", 0x01);
put(Permitted_operands, "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
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
put(Permitted_operands, "21", 0x01);
put(Permitted_operands, "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
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
put(Permitted_operands, "09", 0x01);
put(Permitted_operands, "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
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
put(Permitted_operands, "31", 0x01);
put(Permitted_operands, "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
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
put(Permitted_operands, "39", 0x01);
put(Permitted_operands, "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
4527 - reading commandline arguments The new example ex9 doesn't yet work natively. In the process I've emulated the kernel's role in providing args, implemented a couple of instructions acting on 8-bit operands (useful for ASCII string operations), and begun the start of the standard library (ascii_length is the same as strlen). At the level of SubX we're just only going to support ASCII.
2018-08-30 08:15:45 +00:00
put(Permitted_operands, "88", 0x01);
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
put(Permitted_operands, "89", 0x01);
4527 - reading commandline arguments The new example ex9 doesn't yet work natively. In the process I've emulated the kernel's role in providing args, implemented a couple of instructions acting on 8-bit operands (useful for ASCII string operations), and begun the start of the standard library (ascii_length is the same as strlen). At the level of SubX we're just only going to support ASCII.
2018-08-30 08:15:45 +00:00
put(Permitted_operands, "8a", 0x01);
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
put(Permitted_operands, "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
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
put(Permitted_operands, "87", 0x01);
4718
2018-10-24 22:52:41 +00:00
// copy address (lea)
4503 Include LEA (load effective address) in the SubX subset of x86 ISA.
2018-09-23 06:19:39 +00:00
put(Permitted_operands, "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
bugfix to opcode 8f; it requires subops
2019-06-17 07:24:30 +00:00
put(Permitted_operands, "8f", 0x03); // pop
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
put(Permitted_operands, "d3", 0x03); // shift
4537 Streamline the factorial function; we don't need to save a stack variable into a register before operating on it. All instructions can take a stack variable directly. In the process we found two bugs: a) Opcode f7 was not implemented correctly. It was internally consistent but I'd never validated it against a natively running program. Turns out it encodes multiple instructions, not just 'not'. b) The way we look up imm32 operands was sometimes reading them before disp8/disp32 operands.
2018-09-08 05:13:10 +00:00
put(Permitted_operands, "f7", 0x03); // test/not/mul/div
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
put(Permitted_operands, "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
put(Permitted_operands, "c1", 0x23); // combine
4908 Fix CI. a) Update canonical binaries. b) Fix an out-of-bounds access in `clear-stream`. This also required supporting a new instruction in `subx run` to load an imm8 into rm8.
2019-01-05 09:07:37 +00:00
put(Permitted_operands, "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
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
put(Permitted_operands, "81", 0x43); // combine
4886
2018-12-29 05:26:42 +00:00
put(Permitted_operands, "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
// 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))))
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
void check_operands(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;
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
uint8_t expected_bitvector = get(Permitted_operands, op.data);
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
if (HAS(expected_bitvector, MODRM)) {
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
check_operands_modrm(inst, op);
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
compare_bitvector_modrm(inst, expected_bitvector, op);
}
else {
compare_bitvector(inst, expected_bitvector, 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
}
//: Many instructions can be checked just by comparing bitvectors.
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
void compare_bitvector(const line& inst, uint8_t expected, const word& op) {
if (all_hex_bytes(inst) && has_operands(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
4940
2019-01-21 08:48:42 +00:00
uint8_t bitvector = compute_expected_operand_bitvector(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 (trace_contains_errors()) return; // duplicate operand type
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';
if ((bitvector & 0x1) == (expected & 0x1)) continue; // all good with this operand
const string& optype = Operand_type_name.at(i);
if ((bitvector & 0x1) > (expected & 0x1))
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 << "'" << to_string(inst) << "'" << maybe_name(op) << ": unexpected " << optype << " operand\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
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 << "'" << to_string(inst) << "'" << maybe_name(op) << ": missing " << optype << " operand\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
}
4940
2019-01-21 08:48:42 +00:00
uint32_t compute_expected_operand_bitvector(const line& inst) {
4941
2019-01-21 08:58:45 +00:00
set<string> operands_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) {
4941
2019-01-21 08:58:45 +00:00
bitvector = bitvector | expected_bit_for_received_operand(inst.words.at(i), operands_found, 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 (trace_contains_errors()) return INVALID_OPERANDS; // duplicate operand type
}
return bitvector;
}
bool has_operands(const line& inst) {
return SIZE(inst.words) > first_operand(inst);
}
int first_operand(const line& inst) {
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;
}
4882
2018-12-28 18:29:19 +00:00
// Scan the metadata of 'w' and return the expected bit corresponding to any 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
// Also raise an error if metadata contains multiple operand types.
4941
2019-01-21 08:58:45 +00:00
uint32_t expected_bit_for_received_operand(const word& w, set<string>& instruction_operands, 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;
4882
2018-12-28 18:29:19 +00:00
if (curr == "mod" || curr == "rm32" || curr == "r32" || 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) {
raise << "'" << w.original << "' has conflicting operand types; it should have only one\n" << end();
return INVALID_OPERANDS;
}
4941
2019-01-21 08:58:45 +00:00
if (instruction_operands.find(curr) != instruction_operands.end()) {
raise << "'" << to_string(inst) << "': duplicate " << curr << " operand\n" << end();
return INVALID_OPERANDS;
}
instruction_operands.insert(curr);
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;
}
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_conflicting_operand_type() {
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(
"error: '80/imm8/imm32' has conflicting operand types; it should have only one\n"
);
}
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.
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_mod_operand() {
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(
"error: '81 0/add/subop 3/rm32/ebx 1/imm32' (combine rm32 with imm32 based on subop): missing mod operand\n"
);
}
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
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
void check_operands_modrm(const line& inst, const word& op) {
if (all_hex_bytes(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
check_operand_metadata_present(inst, "mod", op);
check_operand_metadata_present(inst, "rm32", 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
// no check for r32; some instructions don't use it; just assume it's 0 if missing
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 == "81" || op.data == "8f" || op.data == "ff") { // keep sync'd with 'help subop'
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
check_operand_metadata_present(inst, "subop", op);
check_operand_metadata_absent(inst, "r32", 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;
if (metadata(inst, "rm32").data != "4") return;
// SIB byte checks
uint8_t mod = hex_byte(metadata(inst, "mod").data);
if (mod != /*direct*/3) {
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
check_operand_metadata_present(inst, "base", op);
check_operand_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 {
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
check_operand_metadata_absent(inst, "base", op, "direct mode");
check_operand_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
}
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
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
void compare_bitvector_modrm(const line& inst, uint8_t expected, const word& op) {
if (all_hex_bytes(inst) && has_operands(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
4940
2019-01-21 08:48:42 +00:00
uint8_t bitvector = compute_expected_operand_bitvector(inst);
4455 - support displacement in ModR/M Really ugly solution.
2018-07-30 17:16:37 +00:00
if (trace_contains_errors()) return; // duplicate operand 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
if (has_operand_metadata(inst, "mod")) {
int32_t mod = parse_int(metadata(inst, "mod").data);
switch (mod) {
case 0:
if (has_operand_metadata(inst, "rm32") && parse_int(metadata(inst, "rm32").data) == 5)
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';
if ((bitvector & 0x1) == (expected & 0x1)) continue; // all good with this operand
const string& optype = Operand_type_name.at(i);
if ((bitvector & 0x1) > (expected & 0x1))
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": unexpected " << optype << " operand\n" << end();
else
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": missing " << optype << " operand\n" << end();
// continue giving all errors for a single instruction
}
// ignore settings in any unused bits
}
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
void check_operand_metadata_present(const line& inst, const string& type, const word& op) {
if (!has_operand_metadata(inst, type))
4697
2018-10-14 07:29:48 +00:00
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": missing " << type << " operand\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
}
4544 Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
2018-09-13 04:21:31 +00:00
void check_operand_metadata_absent(const line& inst, const string& type, const word& op, const string& msg) {
if (has_operand_metadata(inst, type))
4697
2018-10-14 07:29:48 +00:00
raise << "'" << to_string(inst) << "'" << maybe_name(op) << ": unexpected " << type << " operand (" << 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(
"error: '89/copy 1/mod/lookup+disp8 0/rm32/EAX 1/r32/ECX' (copy r32 to rm32): missing disp8 operand\n"
);
}
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(
"error: '8b/copy 0/mod/indirect 5/rm32/.disp32 2/r32/EDX' (copy rm32 to r32): missing disp32 operand\n"
);
}
void test_conflicting_operands_in_modrm_instruction() {
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(
"error: '01/add 0/mod 3/mod' has conflicting mod operands\n"
);
}
void test_conflicting_operand_type_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
"01/add 0/mod 3/rm32/r32\n"
);
CHECK_TRACE_CONTENTS(
"error: '3/rm32/r32' has conflicting operand types; it should have only one\n"
);
}
void test_check_missing_rm32_operand() {
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(
"error: '81 0/add/subop 0/mod 1/imm32' (combine rm32 with imm32 based on subop): missing rm32 operand\n"
);
}
void test_check_missing_subop_operand() {
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(
"error: '81 0/mod 3/rm32/ebx 1/imm32' (combine rm32 with imm32 based on subop): missing subop operand\n"
);
}
void test_check_missing_base_operand() {
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(
"error: '81 0/add/subop 0/mod/indirect 4/rm32/use-sib 1/imm32' (combine rm32 with imm32 based on subop): missing base operand\n"
);
}
void test_check_missing_index_operand() {
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(
"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 operand\n"
);
}
void test_check_missing_base_operand_2() {
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(
"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 operand\n"
);
}
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(
"error: '89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 4/disp8' (copy r32 to rm32): unexpected disp8 operand\n"
);
}
void test_check_duplicate_operand() {
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(
"error: '89/copy 0/mod/indirect 0/rm32/EAX 1/r32/ECX 1/r32': duplicate r32 operand\n"
);
}
void test_check_base_operand_not_needed_in_direct_mode() {
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(
"error: '59/pop-to-ECX 3/mod/direct 1/rm32/ECX 4/r32/ESP' (pop top of stack to ECX): unexpected modrm operand\n"
);
}
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
void check_operands_0f(const line& inst) {
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;
}
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
check_operands_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
}
void check_operands_f3(const line& /*unused*/) {
raise << "no supported opcodes starting with f3\n" << end();
}
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_operand() {
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(
"error: '0f 84' (jump disp32 bytes away if equal, if ZF is set): missing disp32 operand\n"
);
}
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")
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
map</*op*/string, /*bitvector*/uint8_t> Permitted_operands_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
. Continuation of commit 6f6d458fcd to support unsigned comparisons in 32-bit jumps. Once again, no tests.
2019-07-12 19:56:57 +00:00
put_new(Permitted_operands_0f, "82", 0x10);
put_new(Permitted_operands_0f, "83", 0x10);
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
put_new(Permitted_operands_0f, "84", 0x10);
put_new(Permitted_operands_0f, "85", 0x10);
. Continuation of commit 6f6d458fcd to support unsigned comparisons in 32-bit jumps. Once again, no tests.
2019-07-12 19:56:57 +00:00
put_new(Permitted_operands_0f, "86", 0x10);
put_new(Permitted_operands_0f, "87", 0x10);
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
put_new(Permitted_operands_0f, "8c", 0x10);
put_new(Permitted_operands_0f, "8d", 0x10);
put_new(Permitted_operands_0f, "8e", 0x10);
put_new(Permitted_operands_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
4694 Check for duplicate docstrings.
2018-10-14 06:55:07 +00:00
put_new(Permitted_operands_0f, "af", 0x01);
4450
2018-07-30 16:56:53 +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)
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
void check_operands_0f(const line& inst, const word& op) {
uint8_t expected_bitvector = get(Permitted_operands_0f, op.data);
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
if (HAS(expected_bitvector, MODRM))
check_operands_modrm(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
compare_bitvector_0f(inst, CLEAR(expected_bitvector, MODRM), op);
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
}
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
void compare_bitvector_0f(const line& inst, uint8_t expected, const word& op) {
if (all_hex_bytes(inst) && has_operands(inst)) return; // deliberately programming in raw hex; we'll raise a warning elsewhere
4940
2019-01-21 08:48:42 +00:00
uint8_t bitvector = compute_expected_operand_bitvector(inst);
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
if (trace_contains_errors()) return; // duplicate operand type
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';
if ((bitvector & 0x1) == (expected & 0x1)) continue; // all good with this operand
const string& optype = Operand_type_name.at(i);
if ((bitvector & 0x1) > (expected & 0x1))
4697
2018-10-14 07:29:48 +00:00
raise << "'" << to_string(inst) << "'" << maybe_name_0f(op) << ": unexpected " << optype << " operand\n" << end();
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
else
4697
2018-10-14 07:29:48 +00:00
raise << "'" << to_string(inst) << "'" << maybe_name_0f(op) << ": missing " << optype << " operand\n" << end();
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
// continue giving all errors for a single instruction
}
// ignore settings in any unused bits
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
}
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(" ("))+')';
}
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>