From: C. M. <pu...@38...> - 2012-10-27 20:57:35
|
Hi Frank, > I suspect that the license change would apply to this anyway, (I'm also not a lawyer...) It seems likely that this is the case due to the language you used in the relicensing, iff all relevant copyright holders also participated in the relicensing. Otherwise, it is of course possible for something that's still in the repo's history to be only available under the then-applicable licensing, eg 6c98ca4 removed a tool's source which seems to not be legally obtainable under the current (2-clause BSD) licence (at least not via the repo), http://repo.or.cz/w/nasm.git?a=commit;h=6c98ca4ddce52101fb06abff7e65352693a01137 > a notation of which instructions affect which flags would be > a big improvement, IMO. I'm currently using an older manual that still includes the reference (and thus was compiled with the previous licensing in effect). I want to look into compiling it as a document on its own, maybe use Halibut for that. I also want to either embed some additional information and use a viewer that lets me fold all uninteresting sections, or failing that re-order the sections to have the uninteresting ones at the end, or only conditionally compile them into the result. (Most of the time, all post-586 extensions and even all the FPU instructions are uninteresting to me.) Highlighting the 086-/186-/386-compatible instructions also seems like an interesting idea. As far as content changes are concerned, it's still lacking 64-bit mode information (one of the apparent reasons it became obsolete for NASM's manual). I don't use that as of yet though so it's not important to me. Affected flags are a good idea. I'm also interested in recording more detailed semantic descriptions. Regards, Chris |