On 6/2/2023 10:46 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 6/2/2023 2:09 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>>>
>>>>>
>>>>> Again, why do you believe this to be a major weakness, and what
>>>>> "traditional access control" mechanism do you believe is superior?
>>>>>
>>>>
>>>> If you can find a way to forge capabilities, or steal capabilities from
>>>> elsewhere, this shoots a big hole in the security model.
>>>
>>> So how is that any different from any other security model?
>>>
>>> The idea is to make the security footprint as small as possible,
>>> and capabilities are the ideal there, and the corresponding hardware
>>> is easier to make secure.
>>>
>>
>> But, not entirely transparent to "ye olde C".
>
> The CHERI folks have described language extensions to
> adapt C to this type of architecture.
>

Fair enough.

At least with my bounds-check scheme, I was able to use mostly unmodified C.

Main exception was explicit 128-bit pointers within the 64-bit ABI
needing a non-standard keyword ("__huge").

But, this is N/A if not using 128-bit pointers (typically, not used
directly), or if using exclusively 128-bit pointers (though this mode
still needs more debugging work).

>>
>> At least if one accepts all the various ways people like to abuse the
>> language as at least "semi valid".
>
> They can always devolve to in-line assembler (e.g. for OS/Hypervisors)
> to "abuse" the language.
>
>>>
>>> The compilers handle everything. There is no 'significant hindrance
>>> to software development'.
>>>
>>
>> If your language looks like Java or C# or similar.
>
> Two of the top 5 in use today. Python, C++ and soon
> Rust all of which can use capabilites opaque to the
> programmer.
>

OK.

For Python or JavaScript, they have no reason to care.

One downsize though is that capabilities don't allow bit-twiddling the
pointers to encode type-tag bits; and presumably, don't allow falling
back to non-capability pointers (as this would defeat the point).

In my case though, one is allowed to fall back to unchecked pointers,
given the assumption of page-level protections in the background.

Granted, this is likely the most major functional difference between the
models.

Well, and in my project, bounds-checked pointers are merely one type of
pointer, and it also functions as a tagref system, say:
Bare / Object-Type Tagged Pointers;
Various small value types;
Bounds-checked pointers;
Fixnums;
Flonums;
...

In this case, dynamic types are used in a few places as well (and some
of the support mechanisms used for dynamic types are shared with those
used for working with bounds-checked pointers). No current canonical
textual representation for dynamic types though, but if there were, it
would likely sorta resemble JSON or similar.

With bounds-checks disabled, C pointers default to being zero-extended
(untagged). When enabled, the default is to use Bounds-checked pointers
for all array-like types (doesn't bother for structs, but these don't
really hurt anything either).

In the kernel, the "malloc" calls also use bounds-checked pointers, but
this is not currently done in userspace.

>>
>> Or, one is happy to use a subset of C that doesn't allow "abusing"
>> pointers and type-casts in various ways, or makes various other "non
>> portable" assumptions.
>
> You mean code for security rather than convenience. I think you
> overestimate the amount of language abuse that is tolerated in
> production code.
>

Possibly, or a lot of the code I had looked at before is not
particularly portable.

Granted, a fair chunk of the 3rd party code I had ported to BJX2 was
originally written by (or based on code written by) John Carmack back in
the 1990s, not sure how this falls on the spectrum.

Still better than the "raging trash fire" of a lot of the code I saw
that had been released by Apogee / 3D Realms.

Most of it required rewriting parts to work on more modern systems (or
on systems with 64-bit pointers, ...).

Well, and had also used some (older) code originally written by Paul
Edwards (of PDOS fame). But ended up mostly rewriting a lot of it, as
some of it was a bit lacking.

I have tested a few things with bounds-checked pointers:
Doom, Heretic, ROTT, and TestKern itself.

Basically works, though due to misc reasons, seems to generally have
around a 5% performance penalty.

It is possible, that in many cases, the gain in terms of "out of bounds
will immediately trap" outweighs the performance cost, and the overhead
could be reduced slightly by adding more specialized helper cases (such
as a dedicated "compare pointers by address" instruction).

My uses thus far had mostly been debugging-related though (as they can
help catch a lot of subtle bugs one might otherwise miss).

>>
>> But, if someone tries to compile code and the compiler is like "error:
>> that aint gonna fly here", they are liable to blame the architecture
>> rather than fix the code.
>
> Come now, every new warning added to gcc or clang is basically
> 'that ain't gonna fly here' and people aren't blaming anything
> but the compiler, if they complain at all, which they don't in
> general.
>

Fair enough.

I added some warnings for misc things, like emitting a warning whenever
a variable is used without first being initialized. But, the current
implementation has some false positives, to it is necessary sometimes to
add an otherwise frivolous "x=0;" or similar at the top of the function,
even if using the variable uninitialized will not effect the final
result of the function.

Comparably though, GCC and Clang emit lots of warnings (but then allow
some things that are an error in MSVC, like doing pointer arithmetic on
"void *").

Sometimes, comparing warnings between compilers can point out bugs though.

....

On 5/31/2023 11:18 PM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> If 128 bit arithmetic becomes popular, and it is only
>> implemented in the SIMD registers, you could end up with something like
>> the 68000 with separate data versus address registers. :-(
>
> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
> 128-bit arithmetic will become popular enough that popular
> architectures add 128-bit instructions for them. As for 128-bit
> addresses, given the slowdown in semiconductor advances, we may never
> get there.
>
> - anton

Arithmetic already is in the commercial world: 33-digit decimal requires
128. Agreed probably not for a while for raw addresses, but caps need at
least that much.

On 6/1/2023 7:03 PM, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 8:56:55 AM UTC-5, Scott Lurndal wrote:
>>
>> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
> <
> If there is one thing I am smart enough to understand::
> <
> It is that I am not smart enough to grasp capabilities to the extent
> needed to architect a capability machine.
> <
> ............

:-)

The machine is not the problem; you certainly can do that in your sleep.
The problem is the semantics.

scott@slp53.sl.home (Scott Lurndal) writes:
>BGB <cr88192@gmail.com> writes:
>>But, if someone tries to compile code and the compiler is like "error:
>>that aint gonna fly here", they are liable to blame the architecture
>>rather than fix the code.
>
>Come now, every new warning added to gcc or clang is basically
>'that ain't gonna fly here' and people aren't blaming anything
>but the compiler, if they complain at all, which they don't in
>general.

That's because the compiler *is* to blame. E.g., programmers know
that the architectures they use support modulo arithmetic; they know
that the compiler usually performs modulo arithmetic. So when the
compiler does something else in select situations, why would the
programmer blame the architecture?

For comparison, when, as on MacOS on Apple Silicon, my mmap() calls
fail, and these calls work on MacOS on Intel, and on Linux on Apple
Silicon, I blame MacOS.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Ivan Godard <ivan@millcomputing.com> writes:
>On 5/31/2023 11:18 PM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> If 128 bit arithmetic becomes popular, and it is only
>>> implemented in the SIMD registers, you could end up with something like
>>> the 68000 with separate data versus address registers. :-(
>>
>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
>> 128-bit arithmetic will become popular enough that popular
>> architectures add 128-bit instructions for them. As for 128-bit
>> addresses, given the slowdown in semiconductor advances, we may never
>> get there.
>>
>> - anton
>
>Arithmetic already is in the commercial world: 33-digit decimal requires
>128.

A competent programmer gets 38 digits out of 128 bits. I guess you
waste some bits on the decimal FP nonsense. Please show any evidence
that there is significant usage of that. The fact that Intel's
implementation has not been updated in years (and there is a lot of
potential for improvement) speaks against significant usage.

>Agreed probably not for a while for raw addresses, but caps need at
>least that much.

Which have even less usage than decimal FP.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

BGB <cr88192@gmail.com> writes:
>On 6/2/2023 10:46 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 6/2/2023 2:09 PM, Scott Lurndal wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>>>> BGB <cr88192@gmail.com> writes:
>>>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:

>
>OK.
>
>
>For Python or JavaScript, they have no reason to care.
>
>One downsize though is that capabilities don't allow bit-twiddling the
>pointers to encode type-tag bits; and presumably, don't allow falling
>back to non-capability pointers (as this would defeat the point).

A downside? How many programmers have "bit-twiddled" pointers to
encode type-tag bits?

And have you read through the CHERI proposal? IIRC, there's a
"default data" capability that regular pointers would implicitly use.

>
>
>>>
>>> Or, one is happy to use a subset of C that doesn't allow "abusing"
>>> pointers and type-casts in various ways, or makes various other "non
>>> portable" assumptions.
>>
>> You mean code for security rather than convenience. I think you
>> overestimate the amount of language abuse that is tolerated in
>> production code.
>>
>
>Possibly, or a lot of the code I had looked at before is not
>particularly portable.

Or representative.

>Well, and had also used some (older) code originally written by Paul
>Edwards (of PDOS fame). But ended up mostly rewriting a lot of it, as
>some of it was a bit lacking.

Speaking of hardly representative :-)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>BGB <cr88192@gmail.com> writes:
>>>But, if someone tries to compile code and the compiler is like "error:
>>>that aint gonna fly here", they are liable to blame the architecture
>>>rather than fix the code.
>>
>>Come now, every new warning added to gcc or clang is basically
>>'that ain't gonna fly here' and people aren't blaming anything
>>but the compiler, if they complain at all, which they don't in
>>general.
>
>That's because the compiler *is* to blame. E.g., programmers know
>that the architectures they use support modulo arithmetic; they know
>that the compiler usually performs modulo arithmetic. So when the
>compiler does something else in select situations, why would the
>programmer blame the architecture?
>
>For comparison, when, as on MacOS on Apple Silicon, my mmap() calls
>fail, and these calls work on MacOS on Intel, and on Linux on Apple
>Silicon, I blame MacOS.

Given that mmap() is a defined POSIX interface, and Apple claims
compliance to the single unix specification, were you using the
standard capabilities of mmap, or some apple-private flags?

Ivan Godard <ivan@millcomputing.com> writes:
>On 5/31/2023 11:18 PM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> If 128 bit arithmetic becomes popular, and it is only
>>> implemented in the SIMD registers, you could end up with something like
>>> the 68000 with separate data versus address registers. :-(
>>
>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
>> 128-bit arithmetic will become popular enough that popular
>> architectures add 128-bit instructions for them. As for 128-bit
>> addresses, given the slowdown in semiconductor advances, we may never
>> get there.
>>
>> - anton
>
>Arithmetic already is in the commercial world: 33-digit decimal requires
>128. Agreed probably not for a while for raw addresses, but caps need at
>least that much.

Burroughs had 100 digit decimal in the 1960s. Real decimal, not binary
masquerading as decimal.

On Sat, 03 Jun 2023 14:36:46 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>BGB <cr88192@gmail.com> writes:
>>On 6/2/2023 10:46 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 6/2/2023 2:09 PM, Scott Lurndal wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>>>>> BGB <cr88192@gmail.com> writes:
>>>>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>
>>
>>OK.
>>
>>
>>For Python or JavaScript, they have no reason to care.
>>
>>One downsize though is that capabilities don't allow bit-twiddling the
>>pointers to encode type-tag bits; and presumably, don't allow falling
>>back to non-capability pointers (as this would defeat the point).
>
>A downside? How many programmers have "bit-twiddled" pointers to
>encode type-tag bits?

I have. 8-)

But that is the wrong question ... the right question is "how many
programmers use language implementations that bit-twiddle pointers to
encode type tags".

Of course, the answer still is "relatively few". There are better
ways to handle type information than by embedding tags into the
pointers.

>And have you read through the CHERI proposal? IIRC, there's a
>"default data" capability that regular pointers would implicitly use.

I read about CHERI quite some time ago, and I expect things have
changed since - but I can't recall anything in particular that would
prevent, e.g., a BiBOP implementation in which types were segregated
and identified by (some bits of the) object address.

YMMV,
George

George Neuner <gneuner2@comcast.net> writes:
>On Sat, 03 Jun 2023 14:36:46 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>BGB <cr88192@gmail.com> writes:
>>>One downsize though is that capabilities don't allow bit-twiddling the
>>>pointers to encode type-tag bits; and presumably, don't allow falling
>>>back to non-capability pointers (as this would defeat the point).
>>
>>A downside? How many programmers have "bit-twiddled" pointers to
>>encode type-tag bits?
>
>I have. 8-)

And here's another one. And a significant number of the students of
my compiler course.

>But that is the wrong question ... the right question is "how many
>programmers use language implementations that bit-twiddle pointers to
>encode type tags".
>
>Of course, the answer still is "relatively few".

Really? How do Python (TIOBE #1), JavaScript (#7), Scratch (#13),
MATLAB (#15), R (#16) and Ruby (#18) implement their dynamic type
informations?

Also, the real issue is: How many users never use programs written in
a language that encodes type information in pointers?

>There are better
>ways to handle type information than by embedding tags into the
>pointers.

I don't think there are better ways for Prolog, and probably a number
of other dynamically-typed programming languages. There is a reason
why this technique is used. And ARM, AMD, and Intel have added
architectural features to better support this usage
<https://lwn.net/Articles/888914/>. I think there are many more CPUs
from ARM, AMD, and Intel around than CHERI CPUs.

>I read about CHERI quite some time ago, and I expect things have
>changed since - but I can't recall anything in particular that would
>prevent, e.g., a BiBOP implementation in which types were segregated
>and identified by (some bits of the) object address.

I don't think BiBOP would work with the way we implemented
backtracking in our Prolog implementation.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 5/30/2023 12:31 PM, MitchAlsup wrote:
>> It really depends on what your target(s) is(are).
>> a) do you want to perform 128-bits occasionally,
>> b) do you want to perform 128-bits rather often,
>> c) do you want to perform 128-bits all the time.
>
> I think that is true, but with some caveats.
>
> 1. I don't know what the market today wants. Perhaps John Dallman or
> Thomas Koenig, with their perspective can chime in.

I don't have any special insight. One of the disadvantages of
free software is that you don't get feedback from a fraction of
1-10**(-n) of your users, with n unknown, but presumed to be
six or larger.

I know that IBM cares enough to go through a lot of pain changing
the default ABI from IBM paired double to IEEE 128-bit (with
-mabi=ieeelongdouble).

It was a fine example of software being harder than hardware,
(more difficult to change, presumably).

And their old long double format really wasn't great.

> 2. Whatever the market is today, it will be different some years from
> now. I don't have a prediction as to the speed of adoption, however,

As long as it is not supported in hardware, the performance cost
will mean that people will not use it. There is also the mess
with C's long double and 80-bit floats on x86.

(Fortran has the much better type system).

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>BGB <cr88192@gmail.com> writes:
>>>>But, if someone tries to compile code and the compiler is like "error:
>>>>that aint gonna fly here", they are liable to blame the architecture
>>>>rather than fix the code.
>>>
>>>Come now, every new warning added to gcc or clang is basically
>>>'that ain't gonna fly here' and people aren't blaming anything
>>>but the compiler, if they complain at all, which they don't in
>>>general.
>>
>>That's because the compiler *is* to blame. E.g., programmers know
>>that the architectures they use support modulo arithmetic; they know
>>that the compiler usually performs modulo arithmetic. So when the
>>compiler does something else in select situations, why would the
>>programmer blame the architecture?
>>
>>For comparison, when, as on MacOS on Apple Silicon, my mmap() calls
>>fail, and these calls work on MacOS on Intel, and on Linux on Apple
>>Silicon, I blame MacOS.
>
>Given that mmap() is a defined POSIX interface, and Apple claims
>compliance to the single unix specification, were you using the
>standard capabilities of mmap, or some apple-private flags?

They were certainly not Apple-private. They work on Linux and lots of
other Unix systems. Lowest-common denominator standards like POSIX (I
think SUS has been superseded by the newest POSIXes) or ANSI C are not
an acceptable excuse for breaking programs. Currently the development
version of Gforth does not work on MacOS on Apple Silicon, and working
around Apple's intentional breakage is not high on my agenda, so the
next release will probably not work on MacOS on Apple Silicon. And
the workaround I have in mind will make it significantly slower on
MacOS than on Linux.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Scott Lurndal <scott@slp53.sl.home> schrieb:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>>For comparison, when, as on MacOS on Apple Silicon, my mmap() calls
>>fail, and these calls work on MacOS on Intel, and on Linux on Apple
>>Silicon, I blame MacOS.
>
> Given that mmap() is a defined POSIX interface, and Apple claims
> compliance to the single unix specification, were you using the
> standard capabilities of mmap, or some apple-private flags?

One of the things I don't like about MacOS is that you cannot
extend a shared memory region obtained via mmap() with ftruncate().

This works on Linux, but MacOS does not permit it. That can be a
hassle if you don't know the size of your memory region on startup,
so you have to allocate a huge chunk, hope it's enough and fail
otherwise (which is unfriendly).

I think Windows has the same problem (as far as I remember).

On Friday, June 2, 2023 at 8:16:27 PM UTC+3, MitchAlsup wrote:
> On Friday, June 2, 2023 at 5:03:06 AM UTC-5, Michael S wrote:
> > On Thursday, June 1, 2023 at 4:50:26 AM UTC+3, MitchAlsup wrote:
> > > On Wednesday, May 31, 2023 at 8:04:47 PM UTC-5, robf...@gmail..com wrote:
> > > > On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
> > > > > On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> > > > > > On 5/30/2023 10:54 PM, Anton Ertl wrote:
> > > > > >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > > > > >>> But then how do you propose
> > > > > >>> handling 128 bit arithmetic (both integer and floating), assuming these
> > > > > >>> are requirements? ISTM that if you don't use paired registers, then you
> > > > > >>> have to double the number of register specifiers in each ALU
> > > > > >>> instruction or do something like Mitch's instruction modifier mechanism
> > > > > >>> or go to 128 bit registers.
> > > > > >>
> > > > > >> 128-bit registers look fine to me. AMD64 has them already (the xmm
> > > > > >> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> > > > > >> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> > > > > >> registers). So you just need to add the instructions that use them
> > > > > >> for computing with 128-bit values.
> > > > > >
> > > > > > Fair enough. I agree with Mitch in that I don't like the separate SIMD
> > > > > > register approach, preferring VVM, but that would mean 128 bit GPRs,
> > > > > > which we are not ready for yet. (The key word here is yet. I expect
> > > > > > they will come.) If 128 bit arithmetic becomes popular, and it is only
> > > > > > implemented in the SIMD registers, you could end up with something like
> > > > > > the 68000 with separate data versus address registers. :-(
> > > > > >
> > > > > I would personally much rather see a single unified register file, in
> > > > > any case.
> > > > >
> > > > >
> > > > > An ISA with 128-bit GPRs would be the more preferable option, and one
> > > > > could likely use the large registers either for a large address space,
> > > > > or maybe bounds-checked access or capabilities.
> > > > >
> > > > >
> > > > > Say, Array Pointer:
> > > > > ( 63: 0): Address Field
> > > > > ( 83: 64): Array Size (Scaled)
> > > > > (103: 84): Array Lower Bias
> > > > > (108:104): Array Scale / Exponent
> > > > > (111:109): Array RWX Mode
> > > > > (123:112): Array Element Tag
> > > > > (127:124): Top-Level Tag (Say, 0011 for Array)
> > > > >
> > > > > Could still need fine adjustment, potentially 20 bits is overkill for
> > > > > the size field when combined with an exponent.
> > > > > Say, if we allow an 8B alignment, this allows an array that is 8MB which
> > > > > is, most likely, going to be page-aligned.
> > > > >
> > > > > If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
> > > > > were smaller, this would mean more likely needing to pad arrays in many
> > > > > cases.
> > > > >
> > > > >
> > > > > Main drawback being that, if the program is primarily working with
> > > > > 32-bit 'int' values, then 128-bit registers would be kind of a waste.
> > > > >
> > > > >
> > > > > It is usually only in edge cases that 128-bit integers really "make
> > > > > sense", and even then, existing C compilers tend to not support them.
> > > > >
> > > > > Like, if on many targets, if one does "__int128", the compiler is like
> > > > > "Not supported on this target", this is a disincentive to use them, and
> > > > > means that typically the program will (at most) end up only using half
> > > > > the register.
> > > > >
> > > > >
> > > > > Though, could have the amusing property if, say, one supports fixnum's,
> > > > > and the fixnum ends up having a larger value range than C's 'long' and
> > > > > 'long long' types...
> > > > >
> > > > >
> > > > > Other concerns:
> > > > > Resource cost would likely be higher, as now supporting superscalar is a
> > > > > bit more of an ask;
> > > > > Maximum clock speed would likely be lower;
> > > > > ...
> > > > >
> > > > > Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
> > > > > superscalar).
> > > > >
> > > > >
> > > > > But, yeah, could work...
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > I think 64-bits for the address field may not be enough for a virtual address. I
> > > > seem to recall a demand for 100-bit addressing in an alternate reality, but that
> > > > is probably quite a few years away. I also think it is better to have registers
> > > > just as a plain bucket. As soon as structure is added the design is stuck with
> > > > it. A separate tags file associated with registers might be easier to manage.
> > > >
> > > > I am not so sure about the slowness of a superscalar. I think it may have more
> > > > to do with how full the FPGA is, the size and style of the design. I have been
> > > > able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
> > > > par with many other FPGA designs. Even if it is a few MHz slower the ability of
> > > > OoO to hide latency may make it worth it.
> > > >
> > > > *****
> > > > I cannot believe I ignored Cordic for so long, having discovered its beauty.
> > > <
> > > Beautiful and slow as crap.
> > > <
> > > > Answering my own engineering question, 10-bits max micro-code it is; that
> > > > should be overkill. It should not take very many, if any micro-code words for
> > > > basic trig. Previously seven bits were used for Thor2021, but only about a half
> > > > dozen non-math instructions were micro-coded.
> > > >
> > > > Having done some head scratching over cordic and how to calculate the tan,
> > > > I am thinking of just providing a cordic instruction that takes all three
> > > > arguments and calculates away, and then leave it up to the programmer to
> > > > decide on operands and what is being calculated. I get how to calculate sin
> > > > and cosine via cordic and I think tan finally. Specifying that x, y must be
> > > > fractions between 0 and 1, and that the angle must be radians between 0
> > > > and 2 pi.
> > > >
> > > > I gather that modern processor do not use Cordic, and use polynomial
> > > > expansions instead.
> > > <
> > > Typical SW can perform tan() in 150± cycles.
> > How do you know?
> > From past experience I would guess that you didn't actually measure it, do you?
> <
> https://hal.inria.fr/inria-00070636/document
> and
> http://www.cl.cam.ac.uk/~jrh13/slides/gelato-25may05/slides.pdf
> <
> the later using 2 FMACs simultaneously.
> But there is scant little data on it.

The 1st does not contain results for tan() at all and the second is much faster
than your claim. And both 20 years old. Do you really believe that today's CPUs
are not faster than those of 20 years ago? Especially in throughput?

On 6/3/2023 9:36 AM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 6/2/2023 10:46 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 6/2/2023 2:09 PM, Scott Lurndal wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>>>>> BGB <cr88192@gmail.com> writes:
>>>>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>
>>
>> OK.
>>
>>
>> For Python or JavaScript, they have no reason to care.
>>
>> One downsize though is that capabilities don't allow bit-twiddling the
>> pointers to encode type-tag bits; and presumably, don't allow falling
>> back to non-capability pointers (as this would defeat the point).
>
> A downside? How many programmers have "bit-twiddled" pointers to
> encode type-tag bits?
>

Not sure how many, but it is (AFAIK) a pretty common way to implement
languages like Scheme and similar. IIRC, some of the Ruby
implementations also use this strategy, ...

Whereas, instead, some of the JavaScript implementations went with NaN
boxing (may also be encoded in my case).

Ironically CPython is an exception here as, IIRC, its values are
struct-based rather than using bit-twiddled pointers or similar.

> And have you read through the CHERI proposal? IIRC, there's a
> "default data" capability that regular pointers would implicitly use.
>

I have skimmed through a lot of it, and get the general idea.

May have missed stuff though.

>>
>>
>>>>
>>>> Or, one is happy to use a subset of C that doesn't allow "abusing"
>>>> pointers and type-casts in various ways, or makes various other "non
>>>> portable" assumptions.
>>>
>>> You mean code for security rather than convenience. I think you
>>> overestimate the amount of language abuse that is tolerated in
>>> production code.
>>>
>>
>> Possibly, or a lot of the code I had looked at before is not
>> particularly portable.
>
> Or representative.
>

I have looked at a lot of code in my life besides just old game code.
It seems pretty variable.

>
>> Well, and had also used some (older) code originally written by Paul
>> Edwards (of PDOS fame). But ended up mostly rewriting a lot of it, as
>> some of it was a bit lacking.
>
> Speaking of hardly representative :-)

Yeah.

Stuff replaced:
Most of the math functions:
Originals were prone to:
get stuck in infinite loops;
or give incorrect values;
...
And were horridly slow.
Unrolled Taylor expansion being orders of magnitude faster;
Lots of very naive loops, recursive logic, etc.
...
Removed most of the 'MVS' stuff, ..., All N/A to me;
Rewrote most of the 'string.h' stuff and similar as well:
Looping on bytes for "memcpy()"/etc being painfully slow.
...

Also I am mostly using the MIT license (rather than 'public domain' or CC0).

Doom and similar are GPL, so can't use any code from them in TestKern
(would effectively pollute the whole project with GPL in this case).
But, using them as test programs is OK (however, people will need to
supply their own WADs and similar).

I had almost considered doing a full rewrite of the C library, but
haven't done so mostly due to inertia.

My partial rewrite attempts would have used a different structure:
C library is split into "frontend" and "backend" parts;
Frontend parts are always statically linked with the binary;
Backend is accessed from the front-end via COM-style interface.
The backend would typically be linked with the main executable;
DLLs only get the frontend.
The backend is mostly responsible for file IO and memory management.

This is partly to avoid an annoyance (also happens with MSVCRT), where
each effectively gets its own set of incompatible 'FILE' objects, and
trying to "malloc()" memory in one library and "free()" in another
causes the C library to explode, ...

Better, IMO, if one can "fopen()" in one place and "fread/fclose/..." it
from anywhere, and "malloc()" and "free()" from anywhere in the program.

On many targets, for example, GLIBC is dynamically linked, which has a
similar property.

However, for more subtle reasons, this approach does not map over
perfectly to PE/COFF and DLLs (also a DLL based C library would be
incompatible with "bare metal" booting, since the boot-loader does not
support DLL loading). Whereas, a COM-Interface approach is compatible
with loading DLLs as extension libraries (say, could be later extended
to things like loadable kernel modules and drivers).

In the current implementation, the DLL versions of the C library still
use a COM object for stdio and malloc and similar, but there is no clean
"frontend/backend" split.

Sadly, nor is there a clean divide (in TestKern) between userland
functionality and kernel functionality (and most of the binaries have
the kernel linked in, even if intended to be used in userland). I intend
to fix this eventually (but, for now, it does allow "bare metal" booting
most binaries in the emulator).

Note that my use of the term "COM objects" is a bit more general:
Does not assume use of the relevant parts of the Win32 API
(for probably obvious reasons);
Does not assume MIDL (likewise).
So, it is instead mostly:
VTable objects following a similar structure:
First 4 entries are special/reserved;
First argument of any method is a pointer to the object.
The object begins with a pointer to the VTable;
Anything beyond this first pointer depends on the object instance.

so, for example:
typedef struct FooSomeObject_s FooSomeObject;
typedef struct FooSomeObjectVTable_s FooSomeObjectVTable;

struct FooSomeObjectVTable_s {
void *resv0;
void *resv1;
void *resv2;
void *resv3;
void (*FirstMethod)(FooSomeObject *self);
...
};
struct FooSomeObject_s {
FooSomeObjectVTable *vt;
//... undefined for client code.
};

For imported objects, typically only the vtable pointer is valid, and
the vtable is instead a collection of "generic" methods whos sole
purpose is to capture the argument list and perform the relevant system
call (with the object used to figure out where the call should be directed).

Though, for normal "Load DLL into an application" cases, the object is
"merely" a local interface exported by the main binary.

There are typically C API wrappers, which may also manage things like
wrangling arguments into shared memory areas (say, if a call passes a
BITMAPINFOHEADER pointer, it needs to be in an area where the called API
can access it, well along with any bitmap data and other things).

Internally, there is a "malloc_cat()" function which supplies a
"category" which can be used as a stand-in for calls like
"GlobalAlloc()" in the Win32 API and similar.

Though, I guess I could probably add:
void *tkgGlobalAlloc(size_t size);
Or similar, as an explicit "allocate memory somewhere where TKGDI can
access it" call (and remove the implicit assumption that TKGDI has
access to the caller's heap).

Could in theory use tagged dynamic types, but most of the existing APIs
thus far are passing structs and bulk data, which doesn't map over well.

Likewise, "small object sharing" has considerably higher overhead than
"have a region of memory that is implicitly shared by the parties involved".

Say, for small object sharing:
Effectively, object gets copied from local memory to shared memory, then
copied again into the callee's local memory, then copied back to shared
memory on return, and then back into the original object (can sort of
work for BITMAPINFOHEADER and similar due to biSize, or in contexts
where one can figure out the size of the data in question).

Side Note:

TKGDI partly serves a vaguely similar purpose to GDI, VFW, and MMSYSTEM
(all glued together), but omits most USER32 functionality (as-is, the
idea is that the application would be itself responsible for drawing its
UI).

If I get to it, there may be eventually be a widget toolkit, but it
would likely be based on drawing small DIB BITMAP objects into the
window or similar (well, and/or add a small command-language for things
like drawing lines, text, and performing flood-fill). Note that using
TKRA-GL for widget drawing would be overkill and inefficient (and
creating and filling in bitmap objects to draw a buttons and similar
seems "kinda weak").

I have yet to decide whether things like title bar and similar should be
handled by TKGDI (like in Win32 GDI), or offloaded to the client or
window manager (like in X11). Right at the moment, leaning is that
window decorations will also be client-side (similar to other GUI elements).

On Saturday, June 3, 2023 at 1:46:15 PM UTC-5, Michael S wrote:
> On Friday, June 2, 2023 at 8:16:27 PM UTC+3, MitchAlsup wrote:

> > > > Typical SW can perform tan() in 150± cycles.
> > > How do you know?
> > > From past experience I would guess that you didn't actually measure it, do you?
> > <
> > https://hal.inria.fr/inria-00070636/document
> > and
> > http://www.cl.cam.ac.uk/~jrh13/slides/gelato-25may05/slides.pdf
> > <
> > the later using 2 FMACs simultaneously.
> > But there is scant little data on it.
>
> The 1st does not contain results for tan() at all and the second is much faster
> than your claim. And both 20 years old. Do you really believe that today's CPUs
> are not faster than those of 20 years ago? Especially in throughput?
<
When your question is latency {How many cycles do doing 1 unit of X take)
a throughput answer is avoiding answering the question.
<
The problem is finding scalar version of that kind of data (no SIMD instructions)
to make an apples to apples comparison to what I have to look at.
<
As to whether modern CPUs are faster, the latency of FMAC is now 5 and 6
rather than 4 and 5, and most polynomial evaluations are Horner style with
a dependence from iteration to iteration.
<
That is: if I want to compare 1 evaluation {sin(), cos(), tan(), ...}; I do not want
data saying that one can perform 8 calculations of {...} in 160 cycles and give
20 cycles as representative.

On Saturday, June 3, 2023 at 1:48:34 PM UTC-5, BGB wrote:
> On 6/3/2023 9:36 AM, Scott Lurndal wrote:
> > BGB <cr8...@gmail.com> writes:

> > A downside? How many programmers have "bit-twiddled" pointers to
> > encode type-tag bits?
> >
> Not sure how many, but it is (AFAIK) a pretty common way to implement
> languages like Scheme and similar. IIRC, some of the Ruby
> implementations also use this strategy, ...
<
I used the infamous XOR trick to keep doubly linked list in 1 container....
On a PDP-11 to fit an application into memory (64Kb PDP-11/20).
>

On 6/3/2023 12:40 PM, Anton Ertl wrote:
> George Neuner <gneuner2@comcast.net> writes:
>> On Sat, 03 Jun 2023 14:36:46 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>>> BGB <cr88192@gmail.com> writes:
>>>> One downsize though is that capabilities don't allow bit-twiddling the
>>>> pointers to encode type-tag bits; and presumably, don't allow falling
>>>> back to non-capability pointers (as this would defeat the point).
>>>
>>> A downside? How many programmers have "bit-twiddled" pointers to
>>> encode type-tag bits?
>>
>> I have. 8-)
>
> And here's another one. And a significant number of the students of
> my compiler course.
>

Yeah.

Also my case:
Parts of TestKern;
My prior "BGBScript VM" projects;
Basically a very similar layout in both cases.

It ends up being "rather tempting" when the OS's don't use the full
pointer, and allows common cases to be type-checked without needing to
access memory (nor the need to manage memory for things like "fixnum"
and similar).

Some early versions of the BGBScript VM had used pointer boxing, and
then moved over to allocating arrays and using the offset into the array
as the fixnum. But, later moved over to tagged pointers.

Say, on a 32-bit machine, one could allocate 16MB arrays for fixnum and
flonum, each 24 bit in this case (falling back to boxed values in the
general case).

Where, BGBScript was superficially similar to JavaScript (though, its
successor, BGBScript2, had went in a slightly more Java-like direction).

Ironically, would still fail according to a "strict" definition of the C
rules, as one needs to compare unrelated pointers to determine if the
pointer represented a location within one of these arrays.

>> But that is the wrong question ... the right question is "how many
>> programmers use language implementations that bit-twiddle pointers to
>> encode type tags".
>>
>> Of course, the answer still is "relatively few".
>
> Really? How do Python (TIOBE #1), JavaScript (#7), Scratch (#13),
> MATLAB (#15), R (#16) and Ruby (#18) implement their dynamic type
> informations?
>
> Also, the real issue is: How many users never use programs written in
> a language that encodes type information in pointers?
>

IIRC:
CPython:
Pointer to PyObject, which encodes types itself;
Dunno about other Python implementations.
JavaScript:
NaN Boxing for Spider Monkey;
Pointer tagging for V8.
Ruby:
IIRC, pointer tagging.
Others:
Dunno.

Usual tradeoff of pointer tagging:
Can be faster and lower overhead than an object-based approach;
However, does create more obvious portability concerns...

>> There are better
>> ways to handle type information than by embedding tags into the
>> pointers.
>
> I don't think there are better ways for Prolog, and probably a number
> of other dynamically-typed programming languages. There is a reason
> why this technique is used. And ARM, AMD, and Intel have added
> architectural features to better support this usage
> <https://lwn.net/Articles/888914/>. I think there are many more CPUs
> from ARM, AMD, and Intel around than CHERI CPUs.
>

Yeah.

This is part of why I ended up leaving the top 16 bits of the pointer
for type-tags as default. The need for type-tags seemed to outweigh the
need for more than 256TB of virtual address space in the default case.

For 64-bit pointers, the default behavior is to ignore the tag bits
(unless requested to acknowledge them).

But, 128-bit pointers assume that one follows the ABI tag rules.

When I later ended up using these bits for saving/encoding the CPU mode
(for Link-Register, etc), or encoding some other state bits (for some of
the other registers). This effectively ended up "fixing" the virtual
address space size at 48 bits.

LR (63:48): ISA Mode and Flags;
GBR(63:48): FPU Control/Status Flags;
TTB(63:48): ASID (low bits of TTB encode page-table format)
....

But, so happens, I could also use these bits for bounds-checking, since
C doesn't use them much anyways (in these case, the bounds-checked
pointers exist within the ABI defined dynamic type-system).

But, I was trying to keep is so that programs are not required to follow
the ABI rules (and may instead use their own type-tagging schemes).
Though, some of the helper ops do in-fact assume that the type-tagging
follows the ABI defined rules.

Some other instructions, such as LDTEX operate within the tag bits
(using the tag bits to encode the texture size and format, but reusing
some tags for different purposes; but is special in that one is unlikely
to be passing texture objects through the dynamically typed runtime).

BGBCC can also sort of compile a JavaScript variant as well, and will
follow these rules.

There is also a partial BASIC implementation using this system.
The assumption is that if I later add other script interpreters, they
will also use this system (most likely, say, would use a JS variant as
the canonical script language; "less bad" IMHO than the language Bash
uses, though Bash's language can implicitly execute shell commands, but
I had considered a possible shorthand notation for this).

Say:
var x=3; //normal JS-like command
// comment
/ ls -alt //shell command

But only valid in code blocks within shell scripts.

Well, with shell command possibly interpreting $ as an escape for
variables or expressions.

var dir="/var/tmp";
/ ls -alt $(dir)

Though, possibly, some would object to the (non use) of the normal Bash
scripting language.

>> I read about CHERI quite some time ago, and I expect things have
>> changed since - but I can't recall anything in particular that would
>> prevent, e.g., a BiBOP implementation in which types were segregated
>> and identified by (some bits of the) object address.
>
> I don't think BiBOP would work with the way we implemented
> backtracking in our Prolog implementation.
>
> - anton

On 6/3/2023 2:15 PM, MitchAlsup wrote:
> On Saturday, June 3, 2023 at 1:48:34 PM UTC-5, BGB wrote:
>> On 6/3/2023 9:36 AM, Scott Lurndal wrote:
>>> BGB <cr8...@gmail.com> writes:
>
>>> A downside? How many programmers have "bit-twiddled" pointers to
>>> encode type-tag bits?
>>>
>> Not sure how many, but it is (AFAIK) a pretty common way to implement
>> languages like Scheme and similar. IIRC, some of the Ruby
>> implementations also use this strategy, ...
> <
> I used the infamous XOR trick to keep doubly linked list in 1 container....
> On a PDP-11 to fit an application into memory (64Kb PDP-11/20).

Yeah.

Technically still valid in my case, but not well advised.

I guess the obvious drawback is that if a conservative garbage collector
were ever added, things like XOR'ing the pointers would not be
supportable. But, OTOH, a conservative GC could use the tag bits to
exclude most non-pointers from consideration.

Big obvious drawbacks of having a conservative mark/sweep collector or
similar being already noted...

>>
>

In article <u56frb$29tvu$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid
(Stephen Fuld) wrote:
> On 5/30/2023 12:31 PM, MitchAlsup wrote:
> > It really depends on what your target(s) is(are).
> > a) do you want to perform 128-bits occasionally,
> > b) do you want to perform 128-bits rather often,
> > c) do you want to perform 128-bits all the time.
>
> I think that is true, but with some caveats.
>
> 1. I don't know what the market today wants. Perhaps John Dallman
> or Thomas Koenig, with their perspective can chime in.

The mathematical modeller I work on was carefully designed to exploit
64-bit floats to the safe limits of range and precision. In the last few
years we've started using a small amount of 128-bit software floats, for
things that require unusual precision.

If 128-bit floats were available in hardware, we'd obviously move the
soft float to hardware. The next step would require some thought and
careful design, but it should be possible to expand the size and
precision of the model space dramatically. This would expand the
customers' capabilities dramatically, well beyond what they're currently
asking for.

There would be significant problems with data exchange between modellers
using 64-bit floats and 128-bit floats, simply because the 128-bit
modeller could represent many things that the 64-bit one can't. If it
were up to me, I'd call 128-bit a new product, and have only forwards
compatibility of data. That would also allow us to redesign a bunch of
other things.

I've been hoping for 128-bit floats, to try this kind of thing, since the
early 2000s. I pitched them to AMD but they felt there weren't enough
requests for it to be worth considering. I think it's the kind of change
that needs to be experienced for its full possibilities to be appreciated.

John

Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 5/31/2023 11:18 PM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> If 128 bit arithmetic becomes popular, and it is only
>>>> implemented in the SIMD registers, you could end up with something like
>>>> the 68000 with separate data versus address registers. :-(
>>>
>>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
>>> 128-bit arithmetic will become popular enough that popular
>>> architectures add 128-bit instructions for them. As for 128-bit
>>> addresses, given the slowdown in semiconductor advances, we may never
>>> get there.
>>>
>>> - anton
>>
>> Arithmetic already is in the commercial world: 33-digit decimal requires
>> 128.
>
> A competent programmer gets 38 digits out of 128 bits. I guess you
> waste some bits on the decimal FP nonsense. Please show any evidence

Anton, I expect better from you!

Sure, since 2^128 =~ 3.403e38 you can fit signed 38-digit integers in
128 bits, but if you need a more significant dynamic range, then the DFP
standard is actually quite efficient.

> that there is significant usage of that. The fact that Intel's
> implementation has not been updated in years (and there is a lot of
> potential for improvement) speaks against significant usage.
>
>> Agreed probably not for a while for raw addresses, but caps need at
>> least that much.
>
> Which have even less usage than decimal FP.

Possibly to the detriment of current computer users?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Scott Lurndal wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 5/31/2023 11:18 PM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> If 128 bit arithmetic becomes popular, and it is only
>>>> implemented in the SIMD registers, you could end up with something like
>>>> the 68000 with separate data versus address registers. :-(
>>>
>>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
>>> 128-bit arithmetic will become popular enough that popular
>>> architectures add 128-bit instructions for them. As for 128-bit
>>> addresses, given the slowdown in semiconductor advances, we may never
>>> get there.
>>>
>>> - anton
>>
>> Arithmetic already is in the commercial world: 33-digit decimal requires
>> 128. Agreed probably not for a while for raw addresses, but caps need at
>> least that much.
>
> Burroughs had 100 digit decimal in the 1960s. Real decimal, not binary
> masquerading as decimal.
>
Today we have GMP which handles arbitrary precision with ease.

While python defaults to arbitrary precision integers, Perl just need a
'use bigint' near the top of the program.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 6/3/2023 5:49 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 5/31/2023 11:18 PM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> If 128 bit arithmetic becomes popular, and it is only
>>>> implemented in the SIMD registers, you could end up with something like
>>>> the 68000 with separate data versus address registers. :-(
>>>
>>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
>>> 128-bit arithmetic will become popular enough that popular
>>> architectures add 128-bit instructions for them. As for 128-bit
>>> addresses, given the slowdown in semiconductor advances, we may never
>>> get there.
>>>
>>> - anton
>>
>> Arithmetic already is in the commercial world: 33-digit decimal requires
>> 128.
>
> A competent programmer gets 38 digits out of 128 bits. I guess you
> waste some bits on the decimal FP nonsense. Please show any evidence
> that there is significant usage of that. The fact that Intel's
> implementation has not been updated in years (and there is a lot of
> potential for improvement) speaks against significant usage.
>

Depends on usage probably.

Packed BCD, 32 digits;
DPD: 38 digits (36 in naive case);
4x 9-digits in 32-bit linear integer, 36.

For a software implementation, the "9 digits per 32 bits as a linear
integer" strategy probably makes the most sense from a performance POV
as one can mostly leverage normal binary integer operations.

Well, closely by "19 digits per 64 bits as linear integer".

BCD and DPD make more sense for doing it in hardware.

Personally, I don't have a particularly strong use-case for BCD ops, and
the closest I had was "Well, if you have a BCD adder, a trick can be
used to use it for faster number printing".

Had added it as an experiment, but usage was limited as "slightly faster
printf()" isn't particularly notable (and bigger issue were things like
buffering a string of text and sending the whole thing at once, as doing
one syscall, *, per character causes text-printing to look like it is
coming over a serial link...).

*: Well, with in my case, each syscall involving two context switches...

>> Agreed probably not for a while for raw addresses, but caps need at
>> least that much.
>
> Which have even less usage than decimal FP.
>

Probably true...

> - anton

On Saturday, June 3, 2023 at 3:17:21 PM UTC-5, Terje Mathisen wrote:
> Anton Ertl wrote:
> > Ivan Godard <iv...@millcomputing.com> writes:
> >> On 5/31/2023 11:18 PM, Anton Ertl wrote:
> >>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>>> If 128 bit arithmetic becomes popular, and it is only
> >>>> implemented in the SIMD registers, you could end up with something like
> >>>> the 68000 with separate data versus address registers. :-(
> >>>
> >>> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
> >>> 128-bit arithmetic will become popular enough that popular
> >>> architectures add 128-bit instructions for them. As for 128-bit
> >>> addresses, given the slowdown in semiconductor advances, we may never
> >>> get there.
> >>>
> >>> - anton
> >>
> >> Arithmetic already is in the commercial world: 33-digit decimal requires
> >> 128.
> >
> > A competent programmer gets 38 digits out of 128 bits. I guess you
> > waste some bits on the decimal FP nonsense. Please show any evidence
> Anton, I expect better from you!
>
> Sure, since 2^128 =~ 3.403e38 you can fit signed 38-digit integers in
> 128 bits, but if you need a more significant dynamic range, then the DFP
> standard is actually quite efficient.
<
You can represent the GDP of the world in the worlds least valuable currency
in 128-bit.
<
If you need more than that, it is no longer a money problem, but a bignum
problem.
<
> > that there is significant usage of that. The fact that Intel's
> > implementation has not been updated in years (and there is a lot of
> > potential for improvement) speaks against significant usage.
> >
> >> Agreed probably not for a while for raw addresses, but caps need at
> >> least that much.
> >
> > Which have even less usage than decimal FP.
> Possibly to the detriment of current computer users?
>
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Anton Ertl wrote:
>> Ivan Godard <ivan@millcomputing.com> writes:
>>> Arithmetic already is in the commercial world: 33-digit decimal requires
>>> 128.
>>
>> A competent programmer gets 38 digits out of 128 bits. I guess you
>> waste some bits on the decimal FP nonsense. Please show any evidence
>
>Anton, I expect better from you!
>
>Sure, since 2^128 =~ 3.403e38 you can fit signed 38-digit integers in
>128 bits, but if you need a more significant dynamic range

You don't. The commercial rules are designed for fixed-point
computations. So the way to go is with fixed-point of the needed
length (but 38 digits should be good enough). For stuff that needs
dynamic range, you don't need decimal, and therefore use binary FP.

And I guess that's why DFP is not seeing the uptake that its advocates
expected.

>>> Agreed probably not for a while for raw addresses, but caps need at
>>> least that much.
>>
>> Which have even less usage than decimal FP.
>
>Possibly to the detriment of current computer users?

Maybe. Or maybe capabilities are an idee fixe of some people like DFP
is (for a different, but possibly overlapping group of people).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>