Deutsch English Français Italiano |
<vb11t3$1dehl$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Terje Mathisen <terje.mathisen@tmsw.no> Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Sun, 1 Sep 2024 08:34:11 +0200 Organization: A noiseless patient Spider Lines: 116 Message-ID: <vb11t3$1dehl$1@dont-email.me> References: <vajo7i$2s028$1@dont-email.me> <memo.20240827205925.19028i@jgd.cix.co.uk> <valki8$35fk2$1@dont-email.me> <2644ef96e12b369c5fce9231bfc8030d@www.novabbs.org> <vam5qo$3bb7o$1@dont-email.me> <2f1a154a34f72709b0a23ac8e750b02b@www.novabbs.org> <vaoqcf$3r1u3$1@dont-email.me> <2366e332022b8bc8bf2cae9dae663eeb@www.novabbs.org> <vaqgtl$3526$1@dont-email.me> <d0539090a239743b48e51ec4ae7ecffd@www.novabbs.org> <vathse$m1vn$1@dont-email.me> <67b047dcb5e46380694b8cddaf1658bb@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Date: Sun, 01 Sep 2024 08:34:12 +0200 (CEST) Injection-Info: dont-email.me; posting-host="279969ade1e2dbea793b5c6da93d4194"; logging-data="1489461"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ViuRrh1QvvjORaVO3Iw5UggHlcxPuGVfI9C3hlajJyg==" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 Cancel-Lock: sha1:NeFgmcSMd4SFTBwxy8Vf3hHsgFE= In-Reply-To: <67b047dcb5e46380694b8cddaf1658bb@www.novabbs.org> MitchAlsup1 wrote: > On Fri, 30 Aug 2024 22:42:19 +0000, BGB wrote: >=20 >> On 8/30/2024 1:11 PM, MitchAlsup1 wrote: >>> On Thu, 29 Aug 2024 19:07:29 +0000, BGB wrote: >>> Integer Overflow >> >> Not usually a thing. Pretty much everything seems to treat integer >> overflow as silently wrapping. >=20 > ADA wants these. >=20 >> >> >>> Bad Instruction encoding--OpCode exists but not as this >>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0 instruction uses it. Random code gener= ation can use >>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0 every instruction without privilege. >> >> Hit or miss. >> >> Will usually fault on invalid instructions. >=20 > Must be 100% to guarantee upwards compatibility. >=20 >> There is logic in place to reject privileged instructions in user-mode= , >> if the CPU is actually run in user-mode. Some of this is still TODO >> (currently, TestKern is still running everything in Supervisor Mode). >=20 > Yes, it is a pain--but a pain that is absolutely worth it. >=20 >> >> The alternative is to treat them as UB, so they may be one of: >> =C2=A0=C2=A0 Trap; >> =C2=A0=C2=A0 Do something else (like, if an instruction was added); >> =C2=A0=C2=A0 Do something wonky / unintended. >> >> In practice, this seems to be more how it works. >=20 > Bad practice =3D=3D not industrial quality. >=20 >> >> =C2=A0> Bad address--address exists but you are not allowed to touch i= t>=C2=A0 =C3=82=C2=A0=C3=82 >> with LD or ST instruction or to attempt to execute it. >> >> If the MMU is enabled, it should fault on bad memory accesses. >> >> In physical addressing mode, it does not trap. >=20 > YOU FAIL TO UNDERSTAND--there is an area in memory where the > preserved registers are stored--stored in a way that only 3 > instructions can access--and the PTE is marked RWE=3D000 > This prevents damaging the contract between callee and caller. > 3 instructions can access these pages ENTER, EXIT and RET > nothing else. >=20 >> >> IIRC, there was a mechanism on the bus to deal with accesses to bad >> physical addresses (returning all zeroes). Otherwise, trying to access= >> an invalid address would cause the CPU to deadlock. >=20 > It is NOT a BAD address--it is a good but inaccessible address > outside those 3 instructions. >> >> >>> >>> As I understand it, you don't even get FMUL correctly rounded. >>> To get it properly rounded you have to compute the full 53*53 >>> product. >> >> AFAICT, this wasn't required for the 1985 spec... >=20 > You Cannot get rounding correct unless you "compute as if to > infinite precision" and then follow the rules of rounding > (all modes). This rule is in fact really simple: In all versions of the standard, from the very first up to the upcoming=20 2029, the core instructions (FADD/FSUB/FMUL/FDIV/FSQRT) MUST result in=20 the correctly rounded result, according to whatever the current rounding = mode is/was. This does mean that you have to act as if you did the calculation to=20 arbitrary/infinite precision, which really means "enough bits so that=20 any following bits do not matter for the rounding result". It was a revelation to me when I wrote my first fp emulation code and=20 grok'ed how having a single guard bit followed by a sticky bit was=20 sufficient to do this for all rounding modes. At that point I only needed to maintain enough intermediate bits to=20 guarantee I would still have those rounding bits after normalization. This doesn't mean that I could skip calculating all the bits of the full = NxN->2N mantissa product, only that I didn't need to keep them all=20 around after normalization. FMAC (with single rounding, which is the interesting one) you can of=20 course get catastrophic cancellation, so you need all the 2N mantissa=20 bits of the multiplication plus the N bits from the addend, then you=20 either need a normalizer wide enough to take in any possibly alignments=20 of the two parts, or you must have separate logic for each of the major=20 cases. Terje --=20 - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"