Timeline for Is it really time?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2020 at 9:04 | history | edited | CommunityBot |
Commonmark migration
|
|
| Feb 29, 2020 at 20:35 | comment | added | Peter Cordes | re: 23232323: it's not a problem per-se, but if you're spending extra bytes to apply a tight bound for hours, it might not make sense if you don't catch other too-high-number problems. (You could look at it as formatting error vs. semantic error, though.) Re: undocumented opcodes: perhaps an extremely conservative approach to maintaining backwards compat with possible existing binaries? That was Agner Fog's guess in his Stop the Instruction Set War article. | |
| Feb 28, 2020 at 20:34 | comment | added | 640KB |
@PeterCordes you said the code will accept repeated hour pairs. Is that a problem? Rules state input will be only in the range of 0..235959 so shouldn't have to handle 23230000 right?
|
|
| Feb 28, 2020 at 20:33 | comment | added | 640KB |
@PeterCordes brilliant idea eliminating the ASCII conversion before AAD in this case! That never would have occurred to me that it would work in this case! I've changed it to return a DOS exit code instead of output to console. So odd that SALC would be left in all chips and not documented, wonder why? Thanks as always!
|
|
| Feb 28, 2020 at 20:27 | history | edited | 640KB | CC BY-SA 4.0 |
-5 bytes thx to PeterCordes!
|
| Feb 28, 2020 at 0:59 | comment | added | Peter Cordes |
I didn't mean a function, I meant a DOS program that exits with int 21h/ah=4Ch with an exit status of AL = 0 or -1 (from salc = Set AL from Carry - a 1-byte (undocumented) instruction that's like sbb al,al without writing flags). That should save 2 bytes net: drop the ret and turn the 2-byte adc into 1-byte salc. Code-golf answers don't even have to be fully portable, and salc works in 16 and 32-bit mode on at least every Intel CPU including current ones.
|
|
| Feb 27, 2020 at 21:40 | comment | added | 640KB |
@PeterCordes yeah, I know I could shave off a few bytes not making it callable and not a standalone DOS .com, just return a ZF or CF. What stopped me was having to refactor everything when I couldn't count on being able to overwrite input string pointer - 1 with the zero pad. I think the only way to return an exit code is to use INT 21H / AH=4CH (a lot more bytes). Give me a bit to digest your previous post and see what we can squeeze out!
|
|
| Feb 27, 2020 at 21:08 | comment | added | Peter Cordes |
Can you use a non-zero exit status instead of printing a '0/1' to save bytes? At least the ret could go.
|
|
| Feb 27, 2020 at 21:05 | comment | added | Peter Cordes |
You're spending a bunch of bytes to check that hours <= 24. The problem statement in the question guarantees that the max integer is 23... so you can make a version that only solves that simpler problem. Also, I think your code will accept repeated hours pairs, like 23230000, so not arbitrary integer. You could just check the tens digits (AH) for being <= '5' in the loop, instead of aad those bytes into a binary integer. (And BTW, I think you can skip the sub ax, '00' before AAD: 10*0x30 + 0x30 = 0x210, so you just need to check that the AAD result in AL is < 60+16 or 24+16).
|
|
| Feb 27, 2020 at 20:55 | comment | added | 640KB | Yes, it's quite annoying really because that leading space is counted in the length byte, so you pretty much always have to decrement that before you can use it. | |
| Feb 27, 2020 at 20:53 | comment | added | Peter Cordes | Ah, cs.lmu.edu/~ray/notes/x86assembly and How to pass/retrieve DOS command-line parameters in a 16-bit assembly program? weren't clear about that. Makes sense now, I'd forgotten that DOS allowed a non-whitespace separator between command and args. | |
| Feb 27, 2020 at 20:51 | comment | added | 640KB |
@PeterCordes [80h] is the length byte and [81h] is the char (can only be a space (20H) or a forward slash) between the command invocation and the start of the command line argument string that starts at [82h].
|
|
| Feb 27, 2020 at 20:45 | comment | added | Peter Cordes |
Isn't [SI+1] (81h) the first byte of the arg string that you're overwriting? I would have thought you'd want to store to [si] and just replace the length byte with '0' padding.
|
|
| Feb 25, 2020 at 21:33 | history | edited | 640KB | CC BY-SA 4.0 |
-2 bytes, optimize "3 counter" and ADC
|
| Feb 25, 2020 at 21:19 | history | answered | 640KB | CC BY-SA 4.0 |