4 ms·

You're absolutely right, this wasn't in OP. It seemed like a minor detail at the time. What should the mnemonics be called? SubX is already quite verbose. Woul

You're absolutely right, this wasn't in OP. It seemed like a minor detail at the time. What should the mnemonics be called? SubX is already quite verbose. Would you be willing to put up with long names like `add_immediate`? 32- vs 64-bit is certainly a subjective choice. I outlined some reasons for my choice a year ago: https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week#c_rsqllg https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week.... But 64-bit is certainly a valid processor to target.

e12e 7y ago
Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit. As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)? Now, for mnemonics - I certainly don't know. I suppose I see why they're generally implied in most assemblers... I think add_i is still a lot more readable than 0x83 or whatever. Is there a system to the numbers? Could one "mask" immediate etc (eg ADD|I MEDIATE, MUL|IMMEDIATE or some such? Where the pipe implies xor or something (forgive me, I haven't touched shifts etc in years)). I generally prefer descriptive names to terse names - but for an assembler I don't think it fits to go overboard - not unless you expect to end up with a Forth-like quick ascent to abstraction (like building a macro/substitution that abstract away the add_immediate back to just add). I guess I'm starting to see why primitive text macros a la m4 made its way into no just C (the C preprocessor), but also in various forms in various assemblers... Anyway, as your system needs to to some parsing and expansion (eg: strings to binary numbers, loops, label computation) - would not exposing that as a macro/meta facility make sense? Maybe it's more of a level 2 thing in your design?
- akkartik 7y ago
  Yeah, a simple token-based search/replace is certainly realistic to implement in level 1. The questions for me are: a) Does it really make the code easier for newcomers to read? On the one hand the names are familiar. On the other hand it may make cross-referencing with the Intel manual harder. And you do still end up needing to do that to a certain extent. My online help refers to the standard names in parens: https://github.com/akkartik/mu/blob/3a2d36a93680f2e9eb2bd2a324e4fd83eda2cfdf/opcodes https://github.com/akkartik/mu/blob/3a2d36a93680f2e9eb2bd2a3... b) Is it useful in enough places to be worth the lines of code it takes to implement? In any case, this seems worth exploring. Perhaps we should continue on the project site? I've opened a ticket: https://github.com/akkartik/mu/issues/39 https://github.com/akkartik/mu/issues/39. Perhaps the first step is to just hand-translate some function (say https://github.com/akkartik/mu/blob/master/apps/factorial.subx https://github.com/akkartik/mu/blob/master/apps/factorial.su...) and see how it looks. --- One final word on 32-bit vs 64-bit. I didn't realize when I wrote the comment from a year ago how easy it is to run 32-bit code on 64-bit machines. The reverse is obviously impossible.

e12e 7y ago

Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit. As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)? Now, for mnemonics - I certainly don't know. I suppose I see why they're generally implied in most assemblers... I think add_i is still a lot more readable than 0x83 or whatever. Is there a system to the numbers? Could one "mask" immediate etc (eg ADD|I MEDIATE, MUL|IMMEDIATE or some such? Where the pipe implies xor or something (forgive me, I haven't touched shifts etc in years)). I generally prefer descriptive names to terse names - but for an assembler I don't think it fits to go overboard - not unless you expect to end up with a Forth-like quick ascent to abstraction (like building a macro/substitution that abstract away the add_immediate back to just add). I guess I'm starting to see why primitive text macros a la m4 made its way into no just C (the C preprocessor), but also in various forms in various assemblers... Anyway, as your system needs to to some parsing and expansion (eg: strings to binary numbers, loops, label computation) - would not exposing that as a macro/meta facility make sense? Maybe it's more of a level 2 thing in your design?

akkartik 7y ago
Yeah, a simple token-based search/replace is certainly realistic to implement in level 1. The questions for me are: a) Does it really make the code easier for newcomers to read? On the one hand the names are familiar. On the other hand it may make cross-referencing with the Intel manual harder. And you do still end up needing to do that to a certain extent. My online help refers to the standard names in parens: https://github.com/akkartik/mu/blob/3a2d36a93680f2e9eb2bd2a324e4fd83eda2cfdf/opcodes https://github.com/akkartik/mu/blob/3a2d36a93680f2e9eb2bd2a3... b) Is it useful in enough places to be worth the lines of code it takes to implement? In any case, this seems worth exploring. Perhaps we should continue on the project site? I've opened a ticket: https://github.com/akkartik/mu/issues/39 https://github.com/akkartik/mu/issues/39. Perhaps the first step is to just hand-translate some function (say https://github.com/akkartik/mu/blob/master/apps/factorial.subx https://github.com/akkartik/mu/blob/master/apps/factorial.su...) and see how it looks. --- One final word on 32-bit vs 64-bit. I didn't realize when I wrote the comment from a year ago how easy it is to run 32-bit code on 64-bit machines. The reverse is obviously impossible.