mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 05:45:09 +07:00
b24413180f
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
---|---|---|
.. | ||
control_w.h | ||
div_small.S | ||
div_Xsig.S | ||
errors.c | ||
exception.h | ||
fpu_arith.c | ||
fpu_asm.h | ||
fpu_aux.c | ||
fpu_emu.h | ||
fpu_entry.c | ||
fpu_etc.c | ||
fpu_proto.h | ||
fpu_system.h | ||
fpu_tags.c | ||
fpu_trig.c | ||
get_address.c | ||
load_store.c | ||
Makefile | ||
mul_Xsig.S | ||
poly_2xm1.c | ||
poly_atan.c | ||
poly_l2.c | ||
poly_sin.c | ||
poly_tan.c | ||
poly.h | ||
polynom_Xsig.S | ||
README | ||
reg_add_sub.c | ||
reg_compare.c | ||
reg_constant.c | ||
reg_constant.h | ||
reg_convert.c | ||
reg_divide.c | ||
reg_ld_str.c | ||
reg_mul.c | ||
reg_norm.S | ||
reg_round.S | ||
reg_u_add.S | ||
reg_u_div.S | ||
reg_u_mul.S | ||
reg_u_sub.S | ||
round_Xsig.S | ||
shr_Xsig.S | ||
status_w.h | ||
version.h | ||
wm_shrx.S | ||
wm_sqrt.S |
+---------------------------------------------------------------------------+ | wm-FPU-emu an FPU emulator for 80386 and 80486SX microprocessors. | | | | Copyright (C) 1992,1993,1994,1995,1996,1997,1999 | | W. Metzenthen, 22 Parker St, Ormond, Vic 3163, | | Australia. E-mail billm@melbpc.org.au | | | | This program is free software; you can redistribute it and/or modify | | it under the terms of the GNU General Public License version 2 as | | published by the Free Software Foundation. | | | | This program is distributed in the hope that it will be useful, | | but WITHOUT ANY WARRANTY; without even the implied warranty of | | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | | GNU General Public License for more details. | | | | You should have received a copy of the GNU General Public License | | along with this program; if not, write to the Free Software | | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | | | +---------------------------------------------------------------------------+ wm-FPU-emu is an FPU emulator for Linux. It is derived from wm-emu387 which was my 80387 emulator for early versions of djgpp (gcc under msdos); wm-emu387 was in turn based upon emu387 which was written by DJ Delorie for djgpp. The interface to the Linux kernel is based upon the original Linux math emulator by Linus Torvalds. My target FPU for wm-FPU-emu is that described in the Intel486 Programmer's Reference Manual (1992 edition). Unfortunately, numerous facets of the functioning of the FPU are not well covered in the Reference Manual. The information in the manual has been supplemented with measurements on real 80486's. Unfortunately, it is simply not possible to be sure that all of the peculiarities of the 80486 have been discovered, so there is always likely to be obscure differences in the detailed behaviour of the emulator and a real 80486. wm-FPU-emu does not implement all of the behaviour of the 80486 FPU, but is very close. See "Limitations" later in this file for a list of some differences. Please report bugs, etc to me at: billm@melbpc.org.au or b.metzenthen@medoto.unimelb.edu.au For more information on the emulator and on floating point topics, see my web pages, currently at http://www.suburbia.net/~billm/ --Bill Metzenthen December 1999 ----------------------- Internals of wm-FPU-emu ----------------------- Numeric algorithms: (1) Add, subtract, and multiply. Nothing remarkable in these. (2) Divide has been tuned to get reasonable performance. The algorithm is not the obvious one which most people seem to use, but is designed to take advantage of the characteristics of the 80386. I expect that it has been invented many times before I discovered it, but I have not seen it. It is based upon one of those ideas which one carries around for years without ever bothering to check it out. (3) The sqrt function has been tuned to get good performance. It is based upon Newton's classic method. Performance was improved by capitalizing upon the properties of Newton's method, and the code is once again structured taking account of the 80386 characteristics. (4) The trig, log, and exp functions are based in each case upon quasi- "optimal" polynomial approximations. My definition of "optimal" was based upon getting good accuracy with reasonable speed. (5) The argument reducing code for the trig function effectively uses a value of pi which is accurate to more than 128 bits. As a consequence, the reduced argument is accurate to more than 64 bits for arguments up to a few pi, and accurate to more than 64 bits for most arguments, even for arguments approaching 2^63. This is far superior to an 80486, which uses a value of pi which is accurate to 66 bits. The code of the emulator is complicated slightly by the need to account for a limited form of re-entrancy. Normally, the emulator will emulate each FPU instruction to completion without interruption. However, it may happen that when the emulator is accessing the user memory space, swapping may be needed. In this case the emulator may be temporarily suspended while disk i/o takes place. During this time another process may use the emulator, thereby perhaps changing static variables. The code which accesses user memory is confined to five files: fpu_entry.c reg_ld_str.c load_store.c get_address.c errors.c As from version 1.12 of the emulator, no static variables are used (apart from those in the kernel's per-process tables). The emulator is therefore now fully re-entrant, rather than having just the restricted form of re-entrancy which is required by the Linux kernel. ----------------------- Limitations of wm-FPU-emu ----------------------- There are a number of differences between the current wm-FPU-emu (version 2.01) and the 80486 FPU (apart from bugs). The differences are fewer than those which applied to the 1.xx series of the emulator. Some of the more important differences are listed below: The Roundup flag does not have much meaning for the transcendental functions and its 80486 value with these functions is likely to differ from its emulator value. In a few rare cases the Underflow flag obtained with the emulator will be different from that obtained with an 80486. This occurs when the following conditions apply simultaneously: (a) the operands have a higher precision than the current setting of the precision control (PC) flags. (b) the underflow exception is masked. (c) the magnitude of the exact result (before rounding) is less than 2^-16382. (d) the magnitude of the final result (after rounding) is exactly 2^-16382. (e) the magnitude of the exact result would be exactly 2^-16382 if the operands were rounded to the current precision before the arithmetic operation was performed. If all of these apply, the emulator will set the Underflow flag but a real 80486 will not. NOTE: Certain formats of Extended Real are UNSUPPORTED. They are unsupported by the 80486. They are the Pseudo-NaNs, Pseudoinfinities, and Unnormals. None of these will be generated by an 80486 or by the emulator. Do not use them. The emulator treats them differently in detail from the way an 80486 does. Self modifying code can cause the emulator to fail. An example of such code is: movl %esp,[%ebx] fld1 The FPU instruction may be (usually will be) loaded into the pre-fetch queue of the CPU before the mov instruction is executed. If the destination of the 'movl' overlaps the FPU instruction then the bytes in the prefetch queue and memory will be inconsistent when the FPU instruction is executed. The emulator will be invoked but will not be able to find the instruction which caused the device-not-present exception. For this case, the emulator cannot emulate the behaviour of an 80486DX. Handling of the address size override prefix byte (0x67) has not been extensively tested yet. A major problem exists because using it in vm86 mode can cause a general protection fault. Address offsets greater than 0xffff appear to be illegal in vm86 mode but are quite acceptable (and work) in real mode. A small test program developed to check the addressing, and which runs successfully in real mode, crashes dosemu under Linux and also brings Windows down with a general protection fault message when run under the MS-DOS prompt of Windows 3.1. (The program simply reads data from a valid address). The emulator supports 16-bit protected mode, with one difference from an 80486DX. A 80486DX will allow some floating point instructions to write a few bytes below the lowest address of the stack. The emulator will not allow this in 16-bit protected mode: no instructions are allowed to write outside the bounds set by the protection. ----------------------- Performance of wm-FPU-emu ----------------------- Speed. ----- The speed of floating point computation with the emulator will depend upon instruction mix. Relative performance is best for the instructions which require most computation. The simple instructions are adversely affected by the FPU instruction trap overhead. Timing: Some simple timing tests have been made on the emulator functions. The times include load/store instructions. All times are in microseconds measured on a 33MHz 386 with 64k cache. The Turbo C tests were under ms-dos, the next two columns are for emulators running with the djgpp ms-dos extender. The final column is for wm-FPU-emu in Linux 0.97, using libm4.0 (hard). function Turbo C djgpp 1.06 WM-emu387 wm-FPU-emu + 60.5 154.8 76.5 139.4 - 61.1-65.5 157.3-160.8 76.2-79.5 142.9-144.7 * 71.0 190.8 79.6 146.6 / 61.2-75.0 261.4-266.9 75.3-91.6 142.2-158.1 sin() 310.8 4692.0 319.0 398.5 cos() 284.4 4855.2 308.0 388.7 tan() 495.0 8807.1 394.9 504.7 atan() 328.9 4866.4 601.1 419.5-491.9 sqrt() 128.7 crashed 145.2 227.0 log() 413.1-419.1 5103.4-5354.21 254.7-282.2 409.4-437.1 exp() 479.1 6619.2 469.1 850.8 The performance under Linux is improved by the use of look-ahead code. The following results show the improvement which is obtained under Linux due to the look-ahead code. Also given are the times for the original Linux emulator with the 4.1 'soft' lib. [ Linus' note: I changed look-ahead to be the default under linux, as there was no reason not to use it after I had edited it to be disabled during tracing ] wm-FPU-emu w original w look-ahead 'soft' lib + 106.4 190.2 - 108.6-111.6 192.4-216.2 * 113.4 193.1 / 108.8-124.4 700.1-706.2 sin() 390.5 2642.0 cos() 381.5 2767.4 tan() 496.5 3153.3 atan() 367.2-435.5 2439.4-3396.8 sqrt() 195.1 4732.5 log() 358.0-387.5 3359.2-3390.3 exp() 619.3 4046.4 These figures are now somewhat out-of-date. The emulator has become progressively slower for most functions as more of the 80486 features have been implemented. ----------------------- Accuracy of wm-FPU-emu ----------------------- The accuracy of the emulator is in almost all cases equal to or better than that of an Intel 80486 FPU. The results of the basic arithmetic functions (+,-,*,/), and fsqrt match those of an 80486 FPU. They are the best possible; the error for these never exceeds 1/2 an lsb. The fprem and fprem1 instructions return exact results; they have no error. The following table compares the emulator accuracy for the sqrt(), trig and log functions against the Turbo C "emulator". For this table, each function was tested at about 400 points. Ideal worst-case results would be 64 bits. The reduced Turbo C accuracy of cos() and tan() for arguments greater than pi/4 can be thought of as being related to the precision of the argument x; e.g. an argument of pi/2-(1e-10) which is accurate to 64 bits can result in a relative accuracy in cos() of about 64 + log2(cos(x)) = 31 bits. Function Tested x range Worst result Turbo C (relative bits) sqrt(x) 1 .. 2 64.1 63.2 atan(x) 1e-10 .. 200 64.2 62.8 cos(x) 0 .. pi/2-(1e-10) 64.4 (x <= pi/4) 62.4 64.1 (x = pi/2-(1e-10)) 31.9 sin(x) 1e-10 .. pi/2 64.0 62.8 tan(x) 1e-10 .. pi/2-(1e-10) 64.0 (x <= pi/4) 62.1 64.1 (x = pi/2-(1e-10)) 31.9 exp(x) 0 .. 1 63.1 ** 62.9 log(x) 1+1e-6 .. 2 63.8 ** 62.1 ** The accuracy for exp() and log() is low because the FPU (emulator) does not compute them directly; two operations are required. The emulator passes the "paranoia" tests (compiled with gcc 2.3.3 or later) for 'float' variables (24 bit precision numbers) when precision control is set to 24, 53 or 64 bits, and for 'double' variables (53 bit precision numbers) when precision control is set to 53 bits (a properly performing FPU cannot pass the 'paranoia' tests for 'double' variables when precision control is set to 64 bits). The code for reducing the argument for the trig functions (fsin, fcos, fptan and fsincos) has been improved and now effectively uses a value for pi which is accurate to more than 128 bits precision. As a consequence, the accuracy of these functions for large arguments has been dramatically improved (and is now very much better than an 80486 FPU). There is also now no degradation of accuracy for fcos and fptan for operands close to pi/2. Measured results are (note that the definition of accuracy has changed slightly from that used for the above table): Function Tested x range Worst result (absolute bits) cos(x) 0 .. 9.22e+18 62.0 sin(x) 1e-16 .. 9.22e+18 62.1 tan(x) 1e-16 .. 9.22e+18 61.8 It is possible with some effort to find very large arguments which give much degraded precision. For example, the integer number 8227740058411162616.0 is within about 10e-7 of a multiple of pi. To find the tan (for example) of this number to 64 bits precision it would be necessary to have a value of pi which had about 150 bits precision. The FPU emulator computes the result to about 42.6 bits precision (the correct result is about -9.739715e-8). On the other hand, an 80486 FPU returns 0.01059, which in relative terms is hopelessly inaccurate. For arguments close to critical angles (which occur at multiples of pi/2) the emulator is more accurate than an 80486 FPU. For very large arguments, the emulator is far more accurate. Prior to version 1.20 of the emulator, the accuracy of the results for the transcendental functions (in their principal range) was not as good as the results from an 80486 FPU. From version 1.20, the accuracy has been considerably improved and these functions now give measured worst-case results which are better than the worst-case results given by an 80486 FPU. The following table gives the measured results for the emulator. The number of randomly selected arguments in each case is about half a million. The group of three columns gives the frequency of the given accuracy in number of times per million, thus the second of these columns shows that an accuracy of between 63.80 and 63.89 bits was found at a rate of 133 times per one million measurements for fsin. The results show that the fsin, fcos and fptan instructions return results which are in error (i.e. less accurate than the best possible result (which is 64 bits)) for about one per cent of all arguments between -pi/2 and +pi/2. The other instructions have a lower frequency of results which are in error. The last two columns give the worst accuracy which was found (in bits) and the approximate value of the argument which produced it. frequency (per M) ------------------- --------------- instr arg range # tests 63.7 63.8 63.9 worst at arg bits bits bits bits ----- ------------ ------- ---- ---- ----- ----- -------- fsin (0,pi/2) 547756 0 133 10673 63.89 0.451317 fcos (0,pi/2) 547563 0 126 10532 63.85 0.700801 fptan (0,pi/2) 536274 11 267 10059 63.74 0.784876 fpatan 4 quadrants 517087 0 8 1855 63.88 0.435121 (4q) fyl2x (0,20) 541861 0 0 1323 63.94 1.40923 (x) fyl2xp1 (-.293,.414) 520256 0 0 5678 63.93 0.408542 (x) f2xm1 (-1,1) 538847 4 481 6488 63.79 0.167709 Tests performed on an 80486 FPU showed results of lower accuracy. The following table gives the results which were obtained with an AMD 486DX2/66 (other tests indicate that an Intel 486DX produces identical results). The tests were basically the same as those used to measure the emulator (the values, being random, were in general not the same). The total number of tests for each instruction are given at the end of the table, in case each about 100k tests were performed. Another line of figures at the end of the table shows that most of the instructions return results which are in error for more than 10 percent of the arguments tested. The numbers in the body of the table give the approx number of times a result of the given accuracy in bits (given in the left-most column) was obtained per one million arguments. For three of the instructions, two columns of results are given: * The second column for f2xm1 gives the number cases where the results of the first column were for a positive argument, this shows that this instruction gives better results for positive arguments than it does for negative. * In the cases of fcos and fptan, the first column gives the results when all cases where arguments greater than 1.5 were removed from the results given in the second column. Unlike the emulator, an 80486 FPU returns results of relatively poor accuracy for these instructions when the argument approaches pi/2. The table does not show those cases when the accuracy of the results were less than 62 bits, which occurs quite often for fsin and fptan when the argument approaches pi/2. This poor accuracy is discussed above in relation to the Turbo C "emulator", and the accuracy of the value of pi. bits f2xm1 f2xm1 fpatan fcos fcos fyl2x fyl2xp1 fsin fptan fptan 62.0 0 0 0 0 437 0 0 0 0 925 62.1 0 0 10 0 894 0 0 0 0 1023 62.2 14 0 0 0 1033 0 0 0 0 945 62.3 57 0 0 0 1202 0 0 0 0 1023 62.4 385 0 0 10 1292 0 23 0 0 1178 62.5 1140 0 0 119 1649 0 39 0 0 1149 62.6 2037 0 0 189 1620 0 16 0 0 1169 62.7 5086 14 0 646 2315 10 101 35 39 1402 62.8 8818 86 0 984 3050 59 287 131 224 2036 62.9 11340 1355 0 2126 4153 79 605 357 321 1948 63.0 15557 4750 0 3319 5376 246 1281 862 808 2688 63.1 20016 8288 0 4620 6628 511 2569 1723 1510 3302 63.2 24945 11127 10 6588 8098 1120 4470 2968 2990 4724 63.3 25686 12382 69 8774 10682 1906 6775 4482 5474 7236 63.4 29219 14722 79 11109 12311 3094 9414 7259 8912 10587 63.5 30458 14936 393 13802 15014 5874 12666 9609 13762 15262 63.6 32439 16448 1277 17945 19028 10226 15537 14657 19158 20346 63.7 35031 16805 4067 23003 23947 18910 20116 21333 25001 26209 63.8 33251 15820 7673 24781 25675 24617 25354 24440 29433 30329 63.9 33293 16833 18529 28318 29233 31267 31470 27748 29676 30601 Per cent with error: 30.9 3.2 18.5 9.8 13.1 11.6 17.4 Total arguments tested: 70194 70099 101784 100641 100641 101799 128853 114893 102675 102675 ------------------------- Contributors ------------------------------- A number of people have contributed to the development of the emulator, often by just reporting bugs, sometimes with suggested fixes, and a few kind people have provided me with access in one way or another to an 80486 machine. Contributors include (to those people who I may have forgotten, please forgive me): Linus Torvalds Tommy.Thorn@daimi.aau.dk Andrew.Tridgell@anu.edu.au Nick Holloway, alfie@dcs.warwick.ac.uk Hermano Moura, moura@dcs.gla.ac.uk Jon Jagger, J.Jagger@scp.ac.uk Lennart Benschop Brian Gallew, geek+@CMU.EDU Thomas Staniszewski, ts3v+@andrew.cmu.edu Martin Howell, mph@plasma.apana.org.au M Saggaf, alsaggaf@athena.mit.edu Peter Barker, PETER@socpsy.sci.fau.edu tom@vlsivie.tuwien.ac.at Dan Russel, russed@rpi.edu Daniel Carosone, danielce@ee.mu.oz.au cae@jpmorgan.com Hamish Coleman, t933093@minyos.xx.rmit.oz.au Bruce Evans, bde@kralizec.zeta.org.au Timo Korvola, Timo.Korvola@hut.fi Rick Lyons, rick@razorback.brisnet.org.au Rick, jrs@world.std.com ...and numerous others who responded to my request for help with a real 80486.