Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #81702 > unrolled thread
| Started by | wij <wyniijj@gmail.com> |
|---|---|
| First post | 2021-10-01 08:37 -0700 |
| Last post | 2021-10-03 18:46 -0700 |
| Articles | 20 on this page of 103 — 17 participants |
Back to article view | Back to comp.lang.c++
How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 08:37 -0700
Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-01 16:09 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 14:05 -0400
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 17:23 -0700
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 18:58 +0200
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 19:21 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:18 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:20 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:25 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:53 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 08:09 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-03 11:15 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 12:19 +0200
Re: How to get mantissa of long double? red floyd <no.spam@its.invalid> - 2021-10-03 18:03 -0700
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 09:52 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-04 09:59 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 13:50 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 20:04 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 07:12 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:47 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:46 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 19:04 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:13 +0200
Re: How to get mantissa of long double? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-05 09:04 -0700
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:14 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-05 19:21 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 07:58 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-06 08:11 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 10:25 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-06 14:25 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 16:53 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-06 12:12 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 14:48 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-06 09:44 -0700
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 18:52 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 19:02 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-07 05:35 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:20 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:42 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 10:23 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 20:23 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 10:23 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-09 10:50 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-09 09:02 +0000
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-09 14:57 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-09 12:16 +0100
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 15:10 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-09 10:26 -0700
Re: How to get mantissa of long double? Vir Campestris <vir.campestris@invalid.invalid> - 2021-10-12 21:23 +0100
Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-13 10:30 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:37 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 07:54 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-07 22:44 -0700
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:17 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:39 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-08 09:25 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-08 14:34 +0000
Re: How to get mantissa of long double? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 13:57 -0700
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:34 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:33 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 10:19 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 14:06 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:12 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:48 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-05 05:19 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 10:00 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:47 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 14:37 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:53 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 17:08 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 20:22 +0100
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-01 19:09 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 20:16 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 18:53 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 20:19 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 02:16 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:28 -0400
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:56 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 10:59 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 14:57 -0400
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:37 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:47 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:42 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:35 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 12:09 +0200
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:00 +0200
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:12 -0400
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:23 +0200
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:27 +0200
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 23:19 +0200
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:43 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:45 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:31 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:34 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-04 11:30 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:19 +0000
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 00:35 -0700
Re: How to get mantissa of long double? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-03 15:02 +0100
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 18:46 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-07 10:23 +0200 |
| Message-ID | <sjmaqa$40s$1@dont-email.me> |
| In reply to | #81906 |
On 07/10/2021 08:42, Bonita Montero wrote: > Am 07.10.2021 um 08:38 schrieb Bonita Montero: >> Am 07.10.2021 um 08:20 schrieb David Brown: >> >>> C++20 added std::endian for convenience and standardisation of common >>> compiler features for endianness: >> >> Why an endianess check here ? >> There are no big-endian machines with 80 bit FP. > > Oh, I just remembered the 68K FPUs. These have 80 bit FP. > But 68K is dead today. The 68k ISA lives on in the microcontroller world, as the ColdFire processors, though I don't believe any new ColdFire microcontrollers have been released since NXP bought Freescale in 2015. Even at that stage it was no longer a major development line for Freescale. A decade or so before that, ColdFire was one of the most popular architectures in small network devices such as SOHO NAT routers, and was the main target for the MMU-less Linux version ucLinux. This was all long after the 68k was gone from desktops, workstations, home computers, etc. (Because ucLinux does not support fork(), this lead to an increased use of spawn() instead of fork-exec, which then made porting to Windows easier. So if you use any *nix-heritage software on your Windows machine, that may be partly thanks to the 68k architecture.) Some of the 68k-based microcontrollers are immortal. People still make devices using the renowned 68332, though it is around 30 years old. However, few of these embedded uses used floating point, and the the bigger ColdFire processors with hardware floating point support all used 64-bit floats. 80-bit floats were used in the 68882 FPU co-processor, and the 68040 and 68060 processors. The first serious electronics board I designed had a 68332 with a 68882 co-processor, many years ago. (The current version of the same system is, unsurprisingly, ARM based.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-08 20:23 +0200 |
| Message-ID | <sjq2bp$hf3$1@dont-email.me> |
| In reply to | #81909 |
Am 07.10.2021 um 10:23 schrieb David Brown: > The 68k ISA lives on in the microcontroller world, as the ColdFire > processors, though I don't believe any new ColdFire microcontrollers > have been released since NXP bought Freescale in 2015. Even at that > stage it was no longer a major development line for Freescale. A > decade or so before that, ColdFire was one of the most popular > architectures in small network devices such as SOHO NAT routers, ... MIPS was dominant in routers before it was replaced with ARM. 68K had a straighter instruction-set than x86, but the two times indirect addressing-modes introduced with the 68020 were totally brain-damaged.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-09 10:23 +0200 |
| Message-ID | <sjrji8$oa7$1@dont-email.me> |
| In reply to | #81928 |
On 08/10/2021 20:23, Bonita Montero wrote: > Am 07.10.2021 um 10:23 schrieb David Brown: > >> The 68k ISA lives on in the microcontroller world, as the ColdFire >> processors, though I don't believe any new ColdFire microcontrollers >> have been released since NXP bought Freescale in 2015. Even at that >> stage it was no longer a major development line for Freescale. A >> decade or so before that, ColdFire was one of the most popular >> architectures in small network devices such as SOHO NAT routers, ... > > MIPS was dominant in routers before it was replaced with ARM. MIPS was dominant in high-end routers and fast switches (with PowerPC being the main competitor). ColdFire had a substantial share of the small device market for quite a while, as ucLinux became a popular choice for the system, though MIPS was also used there (mostly with proprietary OSes). Later, MIPS was also used with Linux in such routers, and as you say, ARM is now the most common choice (though MIPS is still used in many low-end and high-end network devices, and PowerPC is still found in some big systems). > 68K had a straighter instruction-set than x86, but the two times > indirect addressing-modes introduced with the 68020 were totally > brain-damaged. 68k was a better ISA than x86 in almost every way imaginable. But it did get a few overly complicated addressing modes - some of these were dropped in later 68k devices. And the /implementation/ in the 68k family was not as good - Motorola didn't have as many smart people and as big budgets as Intel or even AMD. On the 68030, IIRC, someone discovered that a software division routine worked faster than the hardware division instruction. The ColdFire was a clean slate re-implementation of a simplified and modernised 68k ISA. It dropped the more advanced addressing modes and some of the rarely used complex instructions, but added a few new useful ones and streamlined the primary ones. It was marketed as a "variable instruction length RISC architecture". When you look back at the original 68000 compared to the 8086, it is clear that technically the 68000 ISA was a modern and forward-looking architecture while the 8086 was outdated and old-fashioned before the first samples were made. The story of the IBM PC shows how technical brilliance is not enough to succeed - the worst cpu architecture around, combined with the worst OS ever hacked together, ended up dominant.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-09 10:50 +0200 |
| Message-ID | <sjrl51$1eu$1@dont-email.me> |
| In reply to | #81940 |
Am 09.10.2021 um 10:23 schrieb David Brown: >> MIPS was dominant in routers before it was replaced with ARM. > MIPS was dominant in high-end routers and fast switches (with PowerPC > being the main competitor). ... I don't know about former high-end routers, but MIPS was by far the most dominant architecture on SOHO-Routers before ARM. 68k played almost no role then. F.e. in Germany almost anyone uses the Fritz!Box routers and they all were MIPS-based before AVM switched to ARM.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-09 09:02 +0000 |
| Message-ID | <KUc8J.29668$IO1.20300@fx19.iad> |
| In reply to | #81941 |
On 2021-10-09, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 09.10.2021 um 10:23 schrieb David Brown: > >>> MIPS was dominant in routers before it was replaced with ARM. > >> MIPS was dominant in high-end routers and fast switches (with PowerPC >> being the main competitor). ... > > I don't know about former high-end routers, but MIPS was by far > the most dominant architecture on SOHO-Routers before ARM. 68k > played almost no role then. F.e. in Germany almost anyone uses > the Fritz!Box routers and they all were MIPS-based before AVM > switched to ARM. > Well I have router with 1GB of RAM and 4 cores :P running as server :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-10-09 14:57 +0000 |
| Message-ID | <d5i8J.63997$2B4.53773@fx04.iad> |
| In reply to | #81941 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 09.10.2021 um 10:23 schrieb David Brown: > >>> MIPS was dominant in routers before it was replaced with ARM. > >> MIPS was dominant in high-end routers and fast switches (with PowerPC >> being the main competitor). ... > >I don't know about former high-end routers, but MIPS was by far >the most dominant architecture on SOHO-Routers before ARM. 68k >played almost no role then. F.e. in Germany almost anyone uses >the Fritz!Box routers and they all were MIPS-based before AVM >switched to ARM. > There are still very large numbers of MIPS-based chips being produced (at legacy nodes like 65, 45 and 22nm) today. Not new designs, mind, but rather ten to fifteen year old designs. This third generation ARM processor for routers (high-end) is now sampling: https://semiaccurate.com/2021/06/28/marvell-announces-their-5nm-octeon-10-dpu/ https://www.theregister.com/2021/10/06/marvell_ai_chip/
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-09 12:16 +0100 |
| Message-ID | <sjrtm4$n0m$1@dont-email.me> |
| In reply to | #81940 |
On 09/10/2021 09:23, David Brown wrote: > On 08/10/2021 20:23, Bonita Montero wrote: >> 68K had a straighter instruction-set than x86, but the two times >> indirect addressing-modes introduced with the 68020 were totally >> brain-damaged. > > 68k was a better ISA than x86 in almost every way imaginable. But it > did get a few overly complicated addressing modes - some of these were > dropped in later 68k devices. And the /implementation/ in the 68k > family was not as good - Motorola didn't have as many smart people and > as big budgets as Intel or even AMD. On the 68030, IIRC, someone > discovered that a software division routine worked faster than the > hardware division instruction. > > When you look back at the original 68000 compared to the 8086, it is > clear that technically the 68000 ISA was a modern and forward-looking > architecture while the 8086 was outdated and old-fashioned before the > first samples were made. That was my initial impression when I first looked at 68000 in the 80s. Until I had a closer look at the instruction set, with a view to generating code for it from a compiler. Then it had almost as much lack of orthogonality as the 8086. The obvious one is in have two lots of integer registers, 8 Data registers and 8 Address registers, instead of just 16 general registers, so that you are constantly thinking about which register set your operands and intermediate results should go in. (I never got round to using the chip; my company had moved on to doing stuff for the IBM PC, instead of developing own hardware products.) > The story of the IBM PC shows how technical > brilliance is not enough to succeed - the worst cpu architecture around, > combined with the worst OS ever hacked together, ended up dominant. I was looking forward to the Zilog Z80000, but unfortunately that never happened.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-09 15:10 +0200 |
| Message-ID | <sjs4cc$387$1@dont-email.me> |
| In reply to | #81943 |
On 09/10/2021 13:16, Bart wrote: > On 09/10/2021 09:23, David Brown wrote: >> On 08/10/2021 20:23, Bonita Montero wrote: > >>> 68K had a straighter instruction-set than x86, but the two times >>> indirect addressing-modes introduced with the 68020 were totally >>> brain-damaged. >> >> 68k was a better ISA than x86 in almost every way imaginable. But it >> did get a few overly complicated addressing modes - some of these were >> dropped in later 68k devices. And the /implementation/ in the 68k >> family was not as good - Motorola didn't have as many smart people and >> as big budgets as Intel or even AMD. On the 68030, IIRC, someone >> discovered that a software division routine worked faster than the >> hardware division instruction. >> > >> When you look back at the original 68000 compared to the 8086, it is >> clear that technically the 68000 ISA was a modern and forward-looking >> architecture while the 8086 was outdated and old-fashioned before the >> first samples were made. > > That was my initial impression when I first looked at 68000 in the 80s. > > Until I had a closer look at the instruction set, with a view to > generating code for it from a compiler. Then it had almost as much lack > of orthogonality as the 8086. > It is not as orthogonal as most RISC architectures, but a world ahead of x86. > The obvious one is in have two lots of integer registers, 8 Data > registers and 8 Address registers, instead of just 16 general registers, > so that you are constantly thinking about which register set your > operands and intermediate results should go in. Sure. But you have just two sorts of registers - A0..7 and D0..7. Some common instructions can use either set, while ALU and address operations tend to be limited to one set. On the 8086, every register - A, B, C, D, SI, DI, BP, SP - has wildly different uses and instructions. (Later x86 devices got more regular.) > > (I never got round to using the chip; my company had moved on to doing > stuff for the IBM PC, instead of developing own hardware products.) > >> The story of the IBM PC shows how technical >> brilliance is not enough to succeed - the worst cpu architecture around, >> combined with the worst OS ever hacked together, ended up dominant. > > I was looking forward to the Zilog Z80000, but unfortunately that never > happened.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2021-10-09 10:26 -0700 |
| Message-ID | <sjsjc4$dse$1@redfloyd.dont-email.me> |
| In reply to | #81943 |
On 10/9/2021 4:16 AM, Bart wrote: \ > I was looking forward to the Zilog Z80000, but unfortunately that never > happened. Same here. The Z8k had a great instruction set. I was really hoping the Z80000 would succeed.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-10-12 21:23 +0100 |
| Message-ID | <sk4qrm$ht0$1@dont-email.me> |
| In reply to | #81940 |
On 09/10/2021 09:23, David Brown wrote: > When you look back at the original 68000 compared to the 8086, it is > clear that technically the 68000 ISA was a modern and forward-looking > architecture while the 8086 was outdated and old-fashioned before the > first samples were made. The story of the IBM PC shows how technical > brilliance is not enough to succeed - the worst cpu architecture around, > combined with the worst OS ever hacked together, ended up dominant. Very nicely put. Of course one reason for that is the success of the 8080, and its successors the 8085 and Zilog's Z80 (which had an even less regular instruction set). AIUI Intel had a world leader on their hands, and felt that having some sort of compatibility in the next generation was important. While the 6800 had some success (and the 6809 was my favourite 8-bit CPU) it was nowhere near that of the 8080. Andy
[toc] | [prev] | [next] | [standalone]
| From | RadicalRabbit@theburrow.co.uk |
|---|---|
| Date | 2021-10-13 10:30 +0000 |
| Message-ID | <sk6cfq$1ocs$1@gioia.aioe.org> |
| In reply to | #81999 |
On Tue, 12 Oct 2021 21:23:17 +0100 Vir Campestris <vir.campestris@invalid.invalid> wrote: >On 09/10/2021 09:23, David Brown wrote: >> When you look back at the original 68000 compared to the 8086, it is >> clear that technically the 68000 ISA was a modern and forward-looking >> architecture while the 8086 was outdated and old-fashioned before the >> first samples were made. The story of the IBM PC shows how technical >> brilliance is not enough to succeed - the worst cpu architecture around, >> combined with the worst OS ever hacked together, ended up dominant. > >Very nicely put. > >Of course one reason for that is the success of the 8080, and its >successors the 8085 and Zilog's Z80 (which had an even less regular >instruction set). > >AIUI Intel had a world leader on their hands, and felt that having some >sort of compatibility in the next generation was important. > >While the 6800 had some success (and the 6809 was my favourite 8-bit >CPU) it was nowhere near that of the 8080. https://en.wikipedia.org/wiki/Motorola_6809 "In 1980 a 6809 in single-unit quantities was $37 compared to $9 for a Zilog Z80 and $6 for a 6502." Oops. No wonder it sank without trace.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-07 08:38 +0200 |
| Message-ID | <sjm4k9$1f2$1@dont-email.me> |
| In reply to | #81899 |
Am 07.10.2021 um 07:35 schrieb Juha Nieminen:
> red floyd <no.spam.here@its.invalid> wrote:
>>> union
>>> {
>>> long double value;
>>> struct
>>> {
>>> uint64_t mantissa;
>>> uint16_t exponent : 15,
>>> sign : 1;
>>> };
>>> }
>>>
>>> Just store your value into value and extract the mantissa from mantissa.
>>
>> Does anyone know if type punning through a union is still undefined
>> behavior?
>>
>> Also, I believe bitfield allocation is implementation defined.
>
> Also, the above union assumes that the long double value is stored in the
> same byte order as the members of the struct. It also assumes that the long
> double occupies exactly 10 bytes and isn't padded in the wrong end.
It actually fits for all x86-compilers.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-08 04:37 +0000 |
| Message-ID | <sjohug$43a$1@gioia.aioe.org> |
| In reply to | #81904 |
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 07.10.2021 um 07:35 schrieb Juha Nieminen:
>> red floyd <no.spam.here@its.invalid> wrote:
>>>> union
>>>> {
>>>> long double value;
>>>> struct
>>>> {
>>>> uint64_t mantissa;
>>>> uint16_t exponent : 15,
>>>> sign : 1;
>>>> };
>>>> }
>>>>
>>>> Just store your value into value and extract the mantissa from mantissa.
>>>
>>> Does anyone know if type punning through a union is still undefined
>>> behavior?
>>>
>>> Also, I believe bitfield allocation is implementation defined.
>>
>> Also, the above union assumes that the long double value is stored in the
>> same byte order as the members of the struct. It also assumes that the long
>> double occupies exactly 10 bytes and isn't padded in the wrong end.
>
> It actually fits for all x86-compilers.
ARM is becoming more and more common.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-08 07:54 +0200 |
| Message-ID | <sjomdn$750$3@dont-email.me> |
| In reply to | #81920 |
Am 08.10.2021 um 06:37 schrieb Juha Nieminen:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 07.10.2021 um 07:35 schrieb Juha Nieminen:
>>> red floyd <no.spam.here@its.invalid> wrote:
>>>>> union
>>>>> {
>>>>> long double value;
>>>>> struct
>>>>> {
>>>>> uint64_t mantissa;
>>>>> uint16_t exponent : 15,
>>>>> sign : 1;
>>>>> };
>>>>> }
>>>>>
>>>>> Just store your value into value and extract the mantissa from mantissa.
>>>>
>>>> Does anyone know if type punning through a union is still undefined
>>>> behavior?
>>>>
>>>> Also, I believe bitfield allocation is implementation defined.
>>>
>>> Also, the above union assumes that the long double value is stored in the
>>> same byte order as the members of the struct. It also assumes that the long
>>> double occupies exactly 10 bytes and isn't padded in the wrong end.
>>
>> It actually fits for all x86-compilers.
>
> ARM is becoming more and more common.
ARM hasn't 80 bit FP, so there's no need for the above code on ARM.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2021-10-07 22:44 -0700 |
| Message-ID | <sjolr6$4fu$1@redfloyd.dont-email.me> |
| In reply to | #81904 |
On 10/6/2021 11:38 PM, Bonita Montero wrote:
> Am 07.10.2021 um 07:35 schrieb Juha Nieminen:
>> red floyd <no.spam.here@its.invalid> wrote:
>>>> union
>>>> {
>>>> long double value;
>>>> struct
>>>> {
>>>> uint64_t mantissa;
>>>> uint16_t exponent : 15,
>>>> sign : 1;
>>>> };
>>>> }
>>>>
>>>> Just store your value into value and extract the mantissa from
>>>> mantissa.
>>>
>>> Does anyone know if type punning through a union is still undefined
>>> behavior?
>>>
>>> Also, I believe bitfield allocation is implementation defined.
>>
>> Also, the above union assumes that the long double value is stored in the
>> same byte order as the members of the struct. It also assumes that the
>> long
>> double occupies exactly 10 bytes and isn't padded in the wrong end.
>
> It actually fits for all x86-compilers.
Back in the early '80s, there was something called "all-the-world's-
a-vax-running-BSD Syndrome". You appear to have the modern variant,
known as "All-the-world's-an-x86-running-Windows Syndrome."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-07 08:17 +0200 |
| Message-ID | <sjm3dj$r5v$1@dont-email.me> |
| In reply to | #81876 |
On 06/10/2021 18:44, red floyd wrote:
> On 10/6/2021 5:48 AM, Bonita Montero wrote:
>
>>
>> As the 1 high-bit is alwas included in the 64 bit mantissa of a 80 bit
>> FP-value that's much easier. In contrast to smaller FP-values where the
>> one bit implicity except from denormal values or values with the maximum
>> exponent.
>>
>> union
>> {
>> long double value;
>> struct
>> {
>> uint64_t mantissa;
>> uint16_t exponent : 15,
>> sign : 1;
>> };
>> }
>>
>> Just store your value into value and extract the mantissa from mantissa.
>
> Does anyone know if type punning through a union is still undefined
> behavior?
Yes, it is. It's not uncommon to for compilers to generate code as
though it /were/ defined in C++ (it is defined behaviour in C),
especially for unions of simple types. But compilers don't (IME)
guarantee it.
The standard method for accessing "raw" bit patterns that is always
safe, is memcpy(). In C++20, there is now std::bit_cast<>, which also
lets you do get type-punning effects.
(And if anyone tells you type-punning unions "work" in C++, then ask why
std::bit_cast<> was added to the language.)
>
> Also, I believe bitfield allocation is implementation defined.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-08 04:39 +0000 |
| Message-ID | <sjoi1c$43a$2@gioia.aioe.org> |
| In reply to | #81900 |
David Brown <david.brown@hesbynett.no> wrote: > (And if anyone tells you type-punning unions "work" in C++, then ask why > std::bit_cast<> was added to the language.) Why hasn't type-punning been standardized in C++, given that it's standardized in C?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-08 09:25 +0200 |
| Message-ID | <sjorpl$5ki$1@dont-email.me> |
| In reply to | #81921 |
On 08/10/2021 06:39, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> (And if anyone tells you type-punning unions "work" in C++, then ask why >> std::bit_cast<> was added to the language.) > > Why hasn't type-punning been standardized in C++, given that it's > standardized in C? > That's a fair question. First, I think you'd have to ask why was it standardised in C? AFAIUI (and this is from memory rather than reference), in C90 and before, it was quite unclear whether the standards defined type-punning union behaviour. However, code relied on it. It's not something that turns up very often - you very rarely have need for this kind of thing. But because it turns up in low-level code that is in turn used by lots of other code - such as in the heart of a software floating point library - it becomes important. A few compilers, such as gcc, actually documented that type-punning unions worked - most did not, though people expected them to support them. I've never been clear as to whether the C standards committee changed their mind to make type-punning fully defined, or if they simply changed the wording of the standard to make it less ambiguous. In C++, however, the idea of type-punning did not fit in. The original aim was that most C++ code would be about objects that get created using a constructor, maintain an invariant by using methods to access the private data, and get destroyed cleanly with a destructor. Messing directly with the internals of an object using different types - that's the kind of bad behaviour C programmers use, and stops you relying on your types and their safety and correctness. C++ certainly could have made it defined behaviour for unions that are limited to POD types. But they have never done so - maybe there are complicating factors that I haven't thought of. The current idea in C++20 is std::bit_cast<>. I don't know how useful or convenient that will be.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-10-08 14:34 +0000 |
| Message-ID | <%FY7J.221912$T_8.134649@fx48.iad> |
| In reply to | #81926 |
David Brown <david.brown@hesbynett.no> writes:
.
>
>A few compilers, such as gcc, actually documented that type-punning
>unions worked - most did not, though people expected them to support
>them. I've never been clear as to whether the C standards committee
>changed their mind to make type-punning fully defined, or if they simply
>changed the wording of the standard to make it less ambiguous.
>
Reading through the Unisys C compiler manual is interesting, due
to the radically different underlying architecture, for example
in the porting section:
The comparison of negative numbers with unsigned types may behave differently on
A Series systems than on other platforms. Platforms that store arithmetic values in
one's or two's complement form store the sign when assigning to an unsigned type.
On A Series systems, the sign is not stored when assigning to an unsigned type. On
A Series systems, comparing a negative value with the value in an unsigned type will
never be true unless the CHAR2 or UNSIGNED subordinate options of the PORT
compiler control option are used to emulate two's complement arithmetic on
unsigned types. Another workaround is to change negative literals to their one's
complement values (for example, -1 becomes 0xFF).
The representation of scalar types differs between A Series systems and other
platforms. On A Series systems, integer types are 6-bytes in length and start on word
boundaries. Any calculations that assume the size of an integer type to be anything
other than 6 bytes will result in problems when portation occurs.
long Ary[ (sizeof(SomeObject)+3) / sizeof(long)];
The addition of the numeric literal 3 to the size of the type of SomeObject assumes that
sizeof(long) returns 4. In A Series C, sizeof(long) returns 6, causing the calculation
to return unexpected results. The following code fragment illustrates how you can
avoid this type of portation problem:
struct{ unsigned short Type;
unsigned char SeqNum;
} Info;
char *InfoPtr = &Info;
seq = InfoPtr[2];
Using InfoPtr[2] to access SeqNum assumes that bytes 0 and 1 contain the structure
member Type and that byte 2 contains the structure member SeqNum. On A Series
systems, Type occupies bytes 0 to 5, and SeqNum occupies byte 6, which means that
InfoPtr[2] accesses the wrong data.
When a pointer is implicitly or explicitly cast from a pointer to an object of a given
alignment to a pointer to an object of a more strict alignment, the resulting pointer
may not be aligned with the original pointer. For example, casting a pointer to char to a
pointer to int causes the pointer index to be divided by 6 to change from character to
word units. The divide by 6 operation causes the pointer to int to point to the
beginning of the word. If the char pointer points to the middle of the word, the two
pointers do not point to the same data. To catch pointer alignment errors of this type
at run time, use the $BOUNDS(ALIGNMENT) compiler control option.
Two's complement arithmetic is used on many platforms. On A Series systems,
arithmetic is performed on data in signed-magnitude form. This can cause
discrepancies in algorithms that depend on the two's complement representation. For
example, C applications that use encryption algorithms to match data, such as
passwords, between client and server must perform the encryption the same way on
the client-end and the server-end. The differences between the two's complement
and signed-magnitude representation may result in different values when fragments
of data are extracted, encrypted, and reinserted into the data.
To obtain matching results, you can define macros that return arithmetic results in
two's complement form. The following example illustrates macros for two's
complement addition and subtraction:
#define tc_add(arg1, arg2) (((arg1) + (arg2)) & 0xFF)
#define tc_sub(arg1, arg2) (((arg1) + (0x100 - (arg2))) & 0xFF)
The macro errno is defined as an array indexed by the unique stack number of the
execution process when $SET CONCURRENTEXECUTION or
$SHARING=SHAREDBYALL. As a result, each client of a C library has a unique errno
location. [ed. Note stack number in this context is equivalent to task/process id]
Although each errno location starts at zero, the location is not reset to zero when a
client delinks from a library or when another client links with the same stack number.
In order to avoid this issue, the C library should explicitly set errno to zero before
calling a function that sets errno.
Note: The macro errno cannot be used as a declarator when
$CONCURRENTEXECUTION or $SHARING=SHAREDBYALL and any of the standard
heads have been included.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-06 13:57 -0700 |
| Message-ID | <sjl2k9$1o47$1@gioia.aioe.org> |
| In reply to | #81872 |
On 10/6/2021 4:12 AM, Bart wrote:
> On 06/10/2021 06:58, Bonita Montero wrote:
>> Am 05.10.2021 um 20:21 schrieb Bart:
>>> On 05/10/2021 18:14, Bonita Montero wrote:
>>>> Am 05.10.2021 um 18:04 schrieb Keith Thompson:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 05/10/2021 07:12, Bonita Montero wrote:
>>>>>>> Am 04.10.2021 um 20:04 schrieb David Brown:
>>>>>>>
>>>>>>>> MSVC for ARM has 64-bit "long doubles" even on 64-bit ARM, other
>>>>>>>> 64-bit
>>>>>>>> ARM targets have 128-bit (I don't know off-hand if they are IEEE
>>>>>>>> quad
>>>>>>>> precision). For RISC-V, even 32-bit targets have 128-bit "long
>>>>>>>> double".
>>>>>>>
>>>>>>> There isn't any ARM-implementation with 128 bit FP.
>>>>>>
>>>>>> And you know that because ... what? Because you are confusing
>>>>>> hardware
>>>>>> floating point with floating point in general?
>>>>>
>>>>> $ uname -m
>>>>> aarch64
>>>>> $ cat c.c
>>>>> #include <stdio.h>
>>>>> #include <limits.h>
>>>>> #include <float.h>
>>>>>
>>>>> int main(void) {
>>>>> printf("sizeof (long double) = %zu (%zu bits), LDBL_DIG =
>>>>> %d\n",
>>>>> sizeof (long double),
>>>>> CHAR_BIT * sizeof (long double),
>>>>> LDBL_DIG);
>>>>> }
>>>>> $ gcc c.c -o c && ./c
>>>>> sizeof (long double) = 16 (128 bits), LDBL_DIG = 33
>>>>> $
>>>>
>>>> That's pure software - your CPU doesn't natively support 128 bit FP.
>>>>
>>>
>>> Does it matter?
>>
>> Yes, It's rare that you need 128 bit FP and it's even more rare that
>> the speed doesn't matter.
>>
>>
>
> You keep avoiding my point
>
> Suppose you HAVE 80-bit or 128-FP, and need to extract the mantissa, how
> would you do it?
>
> It's like someone asking how to work out the 5th root of a number, and
> you give a method for the square root. Then when pressed, you say that
> is is rare to need a 5th root!
This does seem to be a pattern for her. Humm...
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web