Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <vb11t3$1dehl$1@dont-email.me>
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"