{"action":"created","issue":{"url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/36","repository_url":"https://api.github.com/repos/bo3b/3Dmigoto","labels_url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/36/labels{/name}","comments_url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/36/comments","events_url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/36/events","html_url":"https://github.com/bo3b/3Dmigoto/issues/36","id":125648954,"number":36,"title":"Various Assembler Bugs","user":{"login":"DarkStarSword","id":379749,"avatar_url":"https://avatars.githubusercontent.com/u/379749?v=3","gravatar_id":"","url":"https://api.github.com/users/DarkStarSword","html_url":"https://github.com/DarkStarSword","followers_url":"https://api.github.com/users/DarkStarSword/followers","following_url":"https://api.github.com/users/DarkStarSword/following{/other_user}","gists_url":"https://api.github.com/users/DarkStarSword/gists{/gist_id}","starred_url":"https://api.github.com/users/DarkStarSword/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DarkStarSword/subscriptions","organizations_url":"https://api.github.com/users/DarkStarSword/orgs","repos_url":"https://api.github.com/users/DarkStarSword/repos","events_url":"https://api.github.com/users/DarkStarSword/events{/privacy}","received_events_url":"https://api.github.com/users/DarkStarSword/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-01-08T16:56:56Z","updated_at":"2016-03-09T09:25:25Z","closed_at":null,"body":"Trying to keep track of some of the various bugs in the assembler\r\n\r\n1. This line causes the assembler to enter an infinite loop and fill up memory:\r\n\r\n          // this (e.g. small monitors where the large tiles are smaller than the max\r\n\r\n    Possibly processing brackets before comments? Note that this only happens if the line is indented - possibly ignoring comments that aren't at the start of a line (and we are just fluking that it then ignores the bad \"//\" instruction?)\r\n\r\n2. Assembler will crash if an instruction has fewer than expected arguments. Need to double check, but I think it was something like this:\r\n\r\n        add r1.x, r2.x\r\n\r\n3. ~~Assembler does not currently alter the ISGN and OSGN sections, which will cause issues for adding additional inputs/outputs to shaders~~ Code is now implemented in cmd_Decompiler. Once tested we can use it in game.\r\n\r\n4. Assembler ignores lines indented with a tab instead of spaces\r\n\r\n5. Assembler does not fail on bad instructions, instead it silently drops them\r\n\r\n6. Assembler does not fail if an instruction had more arguments than expected, instead it ignores the extra arguments\r\n\r\n7. Assembler does not handle SV_GSInstanceID semantic\r\n\r\n8. Assembler does not handle enableMinimumPrecision global flag.\r\n\r\nNot strictly bugs:\r\n- Would be nice to add some validation that dcl_temps is exactly 1 larger than the largest temporary register used in the shader\r\n\r\n- Would be nice to validate that instructions and declarations are not intermixed\r\n\r\n- Would be nice to validate that anything referenced in the shader that requires a declaration has been declared\r\n\r\n- ~~Assembler produces multiple warnings from the compiler when built. If these are bugs they should be fixed, if they are not they should be silenced (ideally without using a pragma unless very certain they are harmless). IIRC 64bit builds produce more warnings than 32bit.~~\r\n\r\n- ~~Assembler produces many warnings during static code analysis. These each should be investigated to determine if they signify a bug or a false positive. This should be done on both 32bit and 64bit as the code analysis can miss some bugs in printf like functions when the size depends on the architecture.~~"},"comment":{"url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/comments/194202340","html_url":"https://github.com/bo3b/3Dmigoto/issues/36#issuecomment-194202340","issue_url":"https://api.github.com/repos/bo3b/3Dmigoto/issues/36","id":194202340,"user":{"login":"bo3b","id":6544511,"avatar_url":"https://avatars.githubusercontent.com/u/6544511?v=3","gravatar_id":"","url":"https://api.github.com/users/bo3b","html_url":"https://github.com/bo3b","followers_url":"https://api.github.com/users/bo3b/followers","following_url":"https://api.github.com/users/bo3b/following{/other_user}","gists_url":"https://api.github.com/users/bo3b/gists{/gist_id}","starred_url":"https://api.github.com/users/bo3b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bo3b/subscriptions","organizations_url":"https://api.github.com/users/bo3b/orgs","repos_url":"https://api.github.com/users/bo3b/repos","events_url":"https://api.github.com/users/bo3b/events{/privacy}","received_events_url":"https://api.github.com/users/bo3b/received_events","type":"User","site_admin":false},"created_at":"2016-03-09T09:25:25Z","updated_at":"2016-03-09T09:25:25Z","body":"Pretty sure I've never seen a 3 component swizzle as the starting ASM. As far as I know fxc *always* generates a 4 component swizzle, with repeated final components (for opcodes like mov).  Could be part of the disassembler too though.\r\n\r\nI know I've seen some examples of fxc reordering the swizzle in ways that I am nearly certain would introduce bugs, but if there is some sort of magic happening at the assembly level, that might be why it works.\r\n\r\nMight be related to: https://github.com/bo3b/3Dmigoto/issues/10\r\n"}}