Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry


devel / comp.arch / Re: Getting started with MRISC32

SubjectAuthor
* Getting started with MRISC32Marcus
+* Re: Getting started with MRISC32Thomas Koenig
|`* Re: Getting started with MRISC32Marcus
| +- Re: Getting started with MRISC32Thomas Koenig
| +* Re: Getting started with MRISC32BGB
| |`* Re: Getting started with MRISC32MitchAlsup
| | +* Re: Getting started with MRISC32Marcus
| | |+- Re: Getting started with MRISC32MitchAlsup
| | |`* Re: Getting started with MRISC32MitchAlsup
| | | `* Re: Getting started with MRISC32Thomas Koenig
| | |  `* Re: Getting started with MRISC32BGB
| | |   `- Re: Getting started with MRISC32MitchAlsup
| | `- Re: Getting started with MRISC32BGB
| `* Re: Getting started with MRISC32David Brown
|  +* Re: Getting started with MRISC32BGB
|  |`- Re: Getting started with MRISC32MitchAlsup
|  `- Re: Getting started with MRISC32Marcus
`* Re: Getting started with MRISC32Othman Ahmad
 `* Re: Getting started with MRISC32Marcus
  +* Re: Getting started with MRISC32Ivan Godard
  |`- Re: Getting started with MRISC32Marcus
  `* Re: Getting started with MRISC32Andy Valencia
   `* Re: Getting started with MRISC32BGB
    +- Re: Getting started with MRISC32Thomas Koenig
    `- Re: Getting started with MRISC32Andy Valencia

1
Getting started with MRISC32

<spimfs$rkc$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22320&group=comp.arch#22320

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Getting started with MRISC32
Date: Fri, 17 Dec 2021 19:55:56 +0100
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <spimfs$rkc$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 17 Dec 2021 18:55:56 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6f67e59a95dc83f92342c7224b2aba4b";
logging-data="28300"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vM8z3dLymlYaQ464VAAydm1YOvHiIHLw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:Gkeyj02JdqQbbttTooeyAYph+lM=
Content-Language: en-US
X-Mozilla-News-Host: snews://news.eternal-september.org:563
 by: Marcus - Fri, 17 Dec 2021 18:55 UTC

Hi!

The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
simulator now run on the "big three"). Here's a quick tutorial for
getting started:

https://www.bitsnbites.eu/getting-started-with-mrisc32/

/Marcus

Re: Getting started with MRISC32

<spkgpf$6lj$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22326&group=comp.arch#22326

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-6c47-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 11:30:55 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spkgpf$6lj$1@newsreader4.netcologne.de>
References: <spimfs$rkc$1@dont-email.me>
Injection-Date: Sat, 18 Dec 2021 11:30:55 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-6c47-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:6c47:0:7285:c2ff:fe6c:992d";
logging-data="6835"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sat, 18 Dec 2021 11:30 UTC

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> Hi!
>
> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> simulator now run on the "big three"). Here's a quick tutorial for
> getting started:
>
> https://www.bitsnbites.eu/getting-started-with-mrisc32/

Looks quite interesting.

Do you have any plans to also implement double precision?
This would be needed to run my favorite programming language
and compiler :-)

Re: Getting started with MRISC32

<spkpl9$6s0$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22327&group=comp.arch#22327

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 15:02:16 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <spkpl9$6s0$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 18 Dec 2021 14:02:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="15c3fb1e8fe1d3da221bf1862339a533";
logging-data="7040"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3fp/aqLg6WyRkRLGXmE7A6iQHET0s/ik="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:Wy4dtbMfyV62qGdxH3AcRGoeNpE=
In-Reply-To: <spkgpf$6lj$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: Marcus - Sat, 18 Dec 2021 14:02 UTC

On 2021-12-18, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>> Hi!
>>
>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>> simulator now run on the "big three"). Here's a quick tutorial for
>> getting started:
>>
>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>
> Looks quite interesting.
>
> Do you have any plans to also implement double precision?
> This would be needed to run my favorite programming language
> and compiler :-)
>

Kind of, if you count https://github.com/mbitsnbites/mrisc64

....but MRISC32 will not get DP FP, as the main philosophy is that any
register should be able to hold any supported data type. Since registers
are 32 bits wide (same for vector register elements), no data type that
is larger than 32 bits is supported by the architecture. Not memory
addresses, not integers, not floating-point values.

This is a very conscious decision (to avoid different register and
bus/port widths etc), and the problem with double-precision floating-
point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).

That said I believe that many languages would still work, but with quite
restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
the MRISC32 port of GCC - but it's slow.

/Marcus

Re: Getting started with MRISC32

<spks5o$eqp$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22328&group=comp.arch#22328

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-6c47-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 14:45:12 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spks5o$eqp$1@newsreader4.netcologne.de>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
Injection-Date: Sat, 18 Dec 2021 14:45:12 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-6c47-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:6c47:0:7285:c2ff:fe6c:992d";
logging-data="15193"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sat, 18 Dec 2021 14:45 UTC

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> On 2021-12-18, Thomas Koenig wrote:
>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>> Hi!
>>>
>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>> simulator now run on the "big three"). Here's a quick tutorial for
>>> getting started:
>>>
>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>
>> Looks quite interesting.
>>
>> Do you have any plans to also implement double precision?
>> This would be needed to run my favorite programming language
>> and compiler :-)
>>
>
> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>
> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> register should be able to hold any supported data type. Since registers
> are 32 bits wide (same for vector register elements), no data type that
> is larger than 32 bits is supported by the architecture. Not memory
> addresses, not integers, not floating-point values.
>
> This is a very conscious decision (to avoid different register and
> bus/port widths etc), and the problem with double-precision floating-
> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>
> That said I believe that many languages would still work, but with quite
> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> the MRISC32 port of GCC - but it's slow.

One reason why I am interested in your architecture is the vector
capability for scientific work (and gfortran, since your port
is gcc-based). Emulating double precision sort of defeats that,
naturally.

I guess I'll just wait for the 64-bit version, then.

Re: Getting started with MRISC32

<spl2im$258$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22329&group=comp.arch#22329

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 10:34:28 -0600
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <spl2im$258$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 18 Dec 2021 16:34:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fcf15497748725c5a6b14761bb7bf743";
logging-data="2216"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lkyA30Ecr9X4JYyu1+xEq"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.0
Cancel-Lock: sha1:XnEb5VZunnRg5yvGdGOAjgCsTlI=
In-Reply-To: <spkpl9$6s0$1@dont-email.me>
Content-Language: en-US
 by: BGB - Sat, 18 Dec 2021 16:34 UTC

On 12/18/2021 8:02 AM, Marcus wrote:
> On 2021-12-18, Thomas Koenig wrote:
>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>> Hi!
>>>
>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>> simulator now run on the "big three"). Here's a quick tutorial for
>>> getting started:
>>>
>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>
>> Looks quite interesting.
>>
>> Do you have any plans to also implement double precision?
>> This would be needed to run my favorite programming language
>> and compiler :-)
>>
>
> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>
> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> register should be able to hold any supported data type. Since registers
> are 32 bits wide (same for vector register elements), no data type that
> is larger than 32 bits is supported by the architecture. Not memory
> addresses, not integers, not floating-point values.
>
> This is a very conscious decision (to avoid different register and
> bus/port widths etc), and the problem with double-precision floating-
> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>
> That said I believe that many languages would still work, but with quite
> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> the MRISC32 port of GCC - but it's slow.
>

If you have enough register ports, it could make sense to do double
precision via register pairs. Granted, this option doesn't make much
sense unless the cores are superscalar or VLIW.

I am using register pairs to support most of the 128-bit operations in
BJX2; and implicitly the existence of 128-bit operations depends on the
core supporting WEX (as a result, there are subsets which lack any
support for 128-bit operations).

In my case, I had gone the direction of making "double"/"Binary64" be
the primary floating point representation in registers.

A single-precision FPU could have been cheaper and faster, but one may
find that even programs which are primarily single precision or integer
may still occasionally need to use 'double'. Likewise, if one has a
double-precision FPU, the cheapest option is to also run the
single-precision operations through it.

For "__float128" / "long double", I had fallen back to software
emulation. I had experimented with an hardware support for an
intermediate format for "long double"; where "__float128" and "long
double" would still both be encoded as Binary128, but "long double"
could optionally use hardware instructions with a truncated 96-bit variant.

However, the expanded FPU was expensive enough that this was kind of a
roadblock. Granted, a slightly cheaper alternative would be to use a
slightly smaller format with a 64-bit mantissa (rather than an 80-bit
mantissa), eg:
S.E15.M64.Z48
Vs:
S.E15.M80.Z32

Where Z is ignored on input and filled with zeroes on output.
This would be more modest as it doesn't require making the units wider
internally (they are generally already wide enough to be able to deal
with a 64-bit mantissa; mostly for other reasons).

However, such a format doesn't really gain enough relative to "double"
to really justify having it (apart from its superficial similarity to
the x87 "long double"). Similarly, "in the wild", code which uses "long
double" is infrequent.

Re: Getting started with MRISC32

<d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22331&group=comp.arch#22331

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:27c4:: with SMTP id ge4mr2731293qvb.39.1639850108525;
Sat, 18 Dec 2021 09:55:08 -0800 (PST)
X-Received: by 2002:a05:6820:549:: with SMTP id n9mr5698519ooj.35.1639850108261;
Sat, 18 Dec 2021 09:55:08 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 18 Dec 2021 09:55:08 -0800 (PST)
In-Reply-To: <spl2im$258$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b8ce:84cf:2c07:ff3d;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b8ce:84cf:2c07:ff3d
References: <spimfs$rkc$1@dont-email.me> <spkgpf$6lj$1@newsreader4.netcologne.de>
<spkpl9$6s0$1@dont-email.me> <spl2im$258$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 18 Dec 2021 17:55:08 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 91
 by: MitchAlsup - Sat, 18 Dec 2021 17:55 UTC

On Saturday, December 18, 2021 at 10:34:33 AM UTC-6, BGB wrote:
> On 12/18/2021 8:02 AM, Marcus wrote:
> > On 2021-12-18, Thomas Koenig wrote:
> >> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>> Hi!
> >>>
> >>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> >>> simulator now run on the "big three"). Here's a quick tutorial for
> >>> getting started:
> >>>
> >>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
> >>
> >> Looks quite interesting.
> >>
> >> Do you have any plans to also implement double precision?
> >> This would be needed to run my favorite programming language
> >> and compiler :-)
> >>
> >
> > Kind of, if you count https://github.com/mbitsnbites/mrisc64
> >
> > ...but MRISC32 will not get DP FP, as the main philosophy is that any
> > register should be able to hold any supported data type. Since registers
> > are 32 bits wide (same for vector register elements), no data type that
> > is larger than 32 bits is supported by the architecture. Not memory
> > addresses, not integers, not floating-point values.
> >
> > This is a very conscious decision (to avoid different register and
> > bus/port widths etc), and the problem with double-precision floating-
> > point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
> >
> > That said I believe that many languages would still work, but with quite
> > restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> > the MRISC32 port of GCC - but it's slow.
> >
> If you have enough register ports, it could make sense to do double
> precision via register pairs. Granted, this option doesn't make much
> sense unless the cores are superscalar or VLIW.
<
Allow me to argue that 48-years of observations have proven this
philosophy "wanting" at best. It causes massive consternations in
the register allocator of compilers.
<
So, what can be done?
<
In a first iteration of my GPU ISA I had an instruction called DBLE.
DBLE supplied register fields and the following instruction supplies
more registers and the OpCode (which now pertains to a double
width calculation).
<
In the case of MRISC the best alternative is simply to instantiate
a 64-bit version MRISC64.
>
>
> I am using register pairs to support most of the 128-bit operations in
> BJX2; and implicitly the existence of 128-bit operations depends on the
> core supporting WEX (as a result, there are subsets which lack any
> support for 128-bit operations).
>
> In my case, I had gone the direction of making "double"/"Binary64" be
> the primary floating point representation in registers.
>
> A single-precision FPU could have been cheaper and faster, but one may
> find that even programs which are primarily single precision or integer
> may still occasionally need to use 'double'. Likewise, if one has a
> double-precision FPU, the cheapest option is to also run the
> single-precision operations through it.
>
>
> For "__float128" / "long double", I had fallen back to software
> emulation. I had experimented with an hardware support for an
> intermediate format for "long double"; where "__float128" and "long
> double" would still both be encoded as Binary128, but "long double"
> could optionally use hardware instructions with a truncated 96-bit variant.
>
> However, the expanded FPU was expensive enough that this was kind of a
> roadblock. Granted, a slightly cheaper alternative would be to use a
> slightly smaller format with a 64-bit mantissa (rather than an 80-bit
> mantissa), eg:
> S.E15.M64.Z48
> Vs:
> S.E15.M80.Z32
>
> Where Z is ignored on input and filled with zeroes on output.
> This would be more modest as it doesn't require making the units wider
> internally (they are generally already wide enough to be able to deal
> with a 64-bit mantissa; mostly for other reasons).
>
> However, such a format doesn't really gain enough relative to "double"
> to really justify having it (apart from its superficial similarity to
> the x87 "long double"). Similarly, "in the wild", code which uses "long
> double" is infrequent.

Re: Getting started with MRISC32

<splbmo$144$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22334&group=comp.arch#22334

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 20:10:15 +0100
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <splbmo$144$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spl2im$258$1@dont-email.me>
<d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 18 Dec 2021 19:10:16 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="15c3fb1e8fe1d3da221bf1862339a533";
logging-data="1156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+p+VzlRpIJuKEwWqD0swv2Ho6JUXoeoXw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:gYDdZmXG0QmyVSM2/UsbKNE1v58=
In-Reply-To: <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
Content-Language: en-US
 by: Marcus - Sat, 18 Dec 2021 19:10 UTC

On 2021-12-18, MitchAlsup wrote:
> On Saturday, December 18, 2021 at 10:34:33 AM UTC-6, BGB wrote:
>> On 12/18/2021 8:02 AM, Marcus wrote:
>>> On 2021-12-18, Thomas Koenig wrote:
>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>> Hi!
>>>>>
>>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>>>> simulator now run on the "big three"). Here's a quick tutorial for
>>>>> getting started:
>>>>>
>>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>>
>>>> Looks quite interesting.
>>>>
>>>> Do you have any plans to also implement double precision?
>>>> This would be needed to run my favorite programming language
>>>> and compiler :-)
>>>>
>>>
>>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>>>
>>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
>>> register should be able to hold any supported data type. Since registers
>>> are 32 bits wide (same for vector register elements), no data type that
>>> is larger than 32 bits is supported by the architecture. Not memory
>>> addresses, not integers, not floating-point values.
>>>
>>> This is a very conscious decision (to avoid different register and
>>> bus/port widths etc), and the problem with double-precision floating-
>>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>>>
>>> That said I believe that many languages would still work, but with quite
>>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
>>> the MRISC32 port of GCC - but it's slow.
>>>
>> If you have enough register ports, it could make sense to do double
>> precision via register pairs. Granted, this option doesn't make much
>> sense unless the cores are superscalar or VLIW.
> <
> Allow me to argue that 48-years of observations have proven this
> philosophy "wanting" at best. It causes massive consternations in
> the register allocator of compilers.

Agreed.

> <
> So, what can be done?
> <
> In a first iteration of my GPU ISA I had an instruction called DBLE.
> DBLE supplied register fields and the following instruction supplies
> more registers and the OpCode (which now pertains to a double
> width calculation).
> <
> In the case of MRISC the best alternative is simply to instantiate
> a 64-bit version MRISC64.

Agreed.

>>
>> [snip]
>>

I decided quite early on that I wanted a better solution to FP &
SIMD/Vector than the architectures that I had worked with before. I
investigated various models:

* Split INT/FP reg files (68k, x86/x87, MIPS, RISC-V, ...).
* Split INT/SIMD(FP) reg files (x86/SIMD, AArch64).
* Register pairs (88k, and some other that I can't remember).

None of them really appealed to me. Then I came across Cray, and it was
like "Ok, that's so obvious!". So I decided that FP & INT should go in
the same registers, and for 64-bit FP you need a 64-bit arch (like
Cray, kind of - it didn't have 64-bit address registers, which would
have been an exaggeration at the time).

OTOH I wasn't ready to do a 64-bit architecture when I started out with
my ISA (I'm still learning, and I wanted to ensure that things would go
smoothly with an FPGA implementation), so I went with a 32-bit architecture.

Being a 32-bit ISA, MRISC32 isn't going to cut it for scientific
workloads, but there are plenty of applications where 32 bits are good
enough, and where single precision FP is the norm (no matter how you
look at it, 32-bit provides twice the bandwidth compared to 64-bit, and
for most applications where you know what data ranges you're dealing
with, binary32 is enough).

....and then there's MRISC64. :-)

/Marcus

Re: Getting started with MRISC32

<83a9eaad-17ca-4a63-861f-5b5b3b013399n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22336&group=comp.arch#22336

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:508f:: with SMTP id kk15mr5992723qvb.61.1639862894479;
Sat, 18 Dec 2021 13:28:14 -0800 (PST)
X-Received: by 2002:a05:6808:1248:: with SMTP id o8mr6765519oiv.157.1639862894161;
Sat, 18 Dec 2021 13:28:14 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 18 Dec 2021 13:28:13 -0800 (PST)
In-Reply-To: <splbmo$144$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b8ce:84cf:2c07:ff3d;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b8ce:84cf:2c07:ff3d
References: <spimfs$rkc$1@dont-email.me> <spkgpf$6lj$1@newsreader4.netcologne.de>
<spkpl9$6s0$1@dont-email.me> <spl2im$258$1@dont-email.me> <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
<splbmo$144$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <83a9eaad-17ca-4a63-861f-5b5b3b013399n@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 18 Dec 2021 21:28:14 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 128
 by: MitchAlsup - Sat, 18 Dec 2021 21:28 UTC

On Saturday, December 18, 2021 at 1:10:19 PM UTC-6, Marcus wrote:
> On 2021-12-18, MitchAlsup wrote:
> > On Saturday, December 18, 2021 at 10:34:33 AM UTC-6, BGB wrote:
> >> On 12/18/2021 8:02 AM, Marcus wrote:
> >>> On 2021-12-18, Thomas Koenig wrote:
> >>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>>>> Hi!
> >>>>>
> >>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> >>>>> simulator now run on the "big three"). Here's a quick tutorial for
> >>>>> getting started:
> >>>>>
> >>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
> >>>>
> >>>> Looks quite interesting.
> >>>>
> >>>> Do you have any plans to also implement double precision?
> >>>> This would be needed to run my favorite programming language
> >>>> and compiler :-)
> >>>>
> >>>
> >>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
> >>>
> >>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> >>> register should be able to hold any supported data type. Since registers
> >>> are 32 bits wide (same for vector register elements), no data type that
> >>> is larger than 32 bits is supported by the architecture. Not memory
> >>> addresses, not integers, not floating-point values.
> >>>
> >>> This is a very conscious decision (to avoid different register and
> >>> bus/port widths etc), and the problem with double-precision floating-
> >>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
> >>>
> >>> That said I believe that many languages would still work, but with quite
> >>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> >>> the MRISC32 port of GCC - but it's slow.
> >>>
> >> If you have enough register ports, it could make sense to do double
> >> precision via register pairs. Granted, this option doesn't make much
> >> sense unless the cores are superscalar or VLIW.
> > <
> > Allow me to argue that 48-years of observations have proven this
> > philosophy "wanting" at best. It causes massive consternations in
> > the register allocator of compilers.
> Agreed.
> > <
> > So, what can be done?
> > <
> > In a first iteration of my GPU ISA I had an instruction called DBLE.
> > DBLE supplied register fields and the following instruction supplies
> > more registers and the OpCode (which now pertains to a double
> > width calculation).
> > <
> > In the case of MRISC the best alternative is simply to instantiate
> > a 64-bit version MRISC64.
> Agreed.
>
> >>
> >> [snip]
> >>
>
> I decided quite early on that I wanted a better solution to FP &
> SIMD/Vector than the architectures that I had worked with before. I
> investigated various models:
>
> * Split INT/FP reg files (68k, x86/x87, MIPS, RISC-V, ...).
> * Split INT/SIMD(FP) reg files (x86/SIMD, AArch64).
> * Register pairs (88k, and some other that I can't remember).
>
<
Having programmed in Assembly:: IBM S/360, Univac 1108, PDP-8,
PDP-10, PDP-11, VAX 11/780, S.E.L 32/65 32/87, Denelcore HEP,
Z80, 8080, 8085,
<
Having done microcode for PDP-11/40 to simulate PDP-11/75
floating point (F and G)
<
Having written compilers for:: PDP-11, Denelcore HEP, M88K,
<
Having done ISA extensions for S.E.L. 32/87 (user-user traps for realtime)
<
And having developed the ISA for:: M88K, Samsung GPU, My 66000
<
I can tell you the pressures to do things wrong are vast and the pressures
to do things right are minuscule.
<
> None of them really appealed to me. Then I came across Cray, and it was
> like "Ok, that's so obvious!". So I decided that FP & INT should go in
> the same registers, and for 64-bit FP you need a 64-bit arch (like
> Cray, kind of - it didn't have 64-bit address registers, which would
> have been an exaggeration at the time).
<
Check.
>
> OTOH I wasn't ready to do a 64-bit architecture when I started out with
> my ISA (I'm still learning, and I wanted to ensure that things would go
> smoothly with an FPGA implementation), so I went with a 32-bit architecture.
<
There are only a few "gotchas"
<
When there is a choice make sure any immediates that smell like they should
be 32-bits make them 6-bits so extension to 64-bits is straightforward.
<
The main register file should be wide enough to capture the 99% data
container.
<
You should aim to achieve cache line per cycle into and out of the register
file.
>
> Being a 32-bit ISA, MRISC32 isn't going to cut it for scientific
> workloads, but there are plenty of applications where 32 bits are good
> enough, and where single precision FP is the norm (no matter how you
> look at it, 32-bit provides twice the bandwidth compared to 64-bit, and
> for most applications where you know what data ranges you're dealing
> with, binary32 is enough).
<
This is a cache and memory BW observation. By and large, these arguments
dissipate over time. Witness the first microprocessors having 8-bit data
bus, growing to 16-bits, then 32-bits, then 64-bits,... Now we have on chip
interconnects 1024-bits wide (GPUs),
<
Cache lines have grown from 64-bits to 512-bits over time.
<
Architecture NEEDs to be INDEPENDENT of these effects if it is to have
any semblance of a long life.
>
> ...and then there's MRISC64. :-)
>
> /Marcus

Re: Getting started with MRISC32

<splkmk$r87$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22338&group=comp.arch#22338

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 18 Dec 2021 15:43:46 -0600
Organization: A noiseless patient Spider
Lines: 153
Message-ID: <splkmk$r87$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spl2im$258$1@dont-email.me>
<d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 18 Dec 2021 21:43:48 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fcf15497748725c5a6b14761bb7bf743";
logging-data="27911"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kRGYGPAiTqr4Cwvvonjdi"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.0
Cancel-Lock: sha1:ZjLRzWpuu5fNcyl/K2Y0xt2dwZs=
In-Reply-To: <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
Content-Language: en-US
 by: BGB - Sat, 18 Dec 2021 21:43 UTC

On 12/18/2021 11:55 AM, MitchAlsup wrote:
> On Saturday, December 18, 2021 at 10:34:33 AM UTC-6, BGB wrote:
>> On 12/18/2021 8:02 AM, Marcus wrote:
>>> On 2021-12-18, Thomas Koenig wrote:
>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>> Hi!
>>>>>
>>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>>>> simulator now run on the "big three"). Here's a quick tutorial for
>>>>> getting started:
>>>>>
>>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>>
>>>> Looks quite interesting.
>>>>
>>>> Do you have any plans to also implement double precision?
>>>> This would be needed to run my favorite programming language
>>>> and compiler :-)
>>>>
>>>
>>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>>>
>>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
>>> register should be able to hold any supported data type. Since registers
>>> are 32 bits wide (same for vector register elements), no data type that
>>> is larger than 32 bits is supported by the architecture. Not memory
>>> addresses, not integers, not floating-point values.
>>>
>>> This is a very conscious decision (to avoid different register and
>>> bus/port widths etc), and the problem with double-precision floating-
>>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>>>
>>> That said I believe that many languages would still work, but with quite
>>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
>>> the MRISC32 port of GCC - but it's slow.
>>>
>> If you have enough register ports, it could make sense to do double
>> precision via register pairs. Granted, this option doesn't make much
>> sense unless the cores are superscalar or VLIW.
> <
> Allow me to argue that 48-years of observations have proven this
> philosophy "wanting" at best. It causes massive consternations in
> the register allocator of compilers.
> <
> So, what can be done?
> <
> In a first iteration of my GPU ISA I had an instruction called DBLE.
> DBLE supplied register fields and the following instruction supplies
> more registers and the OpCode (which now pertains to a double
> width calculation).
> <
> In the case of MRISC the best alternative is simply to instantiate
> a 64-bit version MRISC64.

I avoided needing more register bits, in the general case, by imposing
an Even/Odd pairing:
R3:R2, R5:R4, ...

Granted, yeah, it is kinda annoying for the register allocator.

In my case, allocating a register pair will put the register ID in one
of the registers, and a special 'DZR' marker in the other. When the
register is evicted, the DZR marker is evicted as well. Both the even
and odd register need to be available for a given spot to be chosen.

Other options were:
Not have any 128-bit stuff;
Expand registers to 128 bits (sorta like Cell SPE or similar).

Wider registers would have had their own drawbacks though, and to be
effectively usable, pretty much the whole ISA would need to be able to
work with 128b registers.

It is a little nicer though if one has R0..R63, and then mostly use
R32..R63 preferentially for 128-bit types (since the GFPX/FPUX/ALUX
instructions can access these registers without needing to use XGPR or
Op64 encodings), without interfering as much with the lower-numbered
registers.

Eg:
00100 -> R5:R4
00101 -> R37:R36
11110 -> R31:R30
11111 -> R63:R62

>>
>>
>> I am using register pairs to support most of the 128-bit operations in
>> BJX2; and implicitly the existence of 128-bit operations depends on the
>> core supporting WEX (as a result, there are subsets which lack any
>> support for 128-bit operations).
>>
>> In my case, I had gone the direction of making "double"/"Binary64" be
>> the primary floating point representation in registers.
>>
>> A single-precision FPU could have been cheaper and faster, but one may
>> find that even programs which are primarily single precision or integer
>> may still occasionally need to use 'double'. Likewise, if one has a
>> double-precision FPU, the cheapest option is to also run the
>> single-precision operations through it.
>>
>>
>> For "__float128" / "long double", I had fallen back to software
>> emulation. I had experimented with an hardware support for an
>> intermediate format for "long double"; where "__float128" and "long
>> double" would still both be encoded as Binary128, but "long double"
>> could optionally use hardware instructions with a truncated 96-bit variant.
>>
>> However, the expanded FPU was expensive enough that this was kind of a
>> roadblock. Granted, a slightly cheaper alternative would be to use a
>> slightly smaller format with a 64-bit mantissa (rather than an 80-bit
>> mantissa), eg:
>> S.E15.M64.Z48
>> Vs:
>> S.E15.M80.Z32
>>
>> Where Z is ignored on input and filled with zeroes on output.
>> This would be more modest as it doesn't require making the units wider
>> internally (they are generally already wide enough to be able to deal
>> with a 64-bit mantissa; mostly for other reasons).
>>
>> However, such a format doesn't really gain enough relative to "double"
>> to really justify having it (apart from its superficial similarity to
>> the x87 "long double"). Similarly, "in the wild", code which uses "long
>> double" is infrequent.

I went and checked, and have noted that with my current configuration
(single core) I can afford to re-enable the existing 96-bit "Long
Double" / FPUX extension.

Granted, major reason I am stuck with single-core at the moment is
mostly because otherwise the use of 512-bit cache-lines between the L2
cache and DDR controller will push things well outside the resource budget.

It is nice having the bigger 256K L2 cache though, which required giving
up the dedicated VRAM (and using a RAM backed buffer instead) to free up
sufficient Block RAM.

Switching back to 128-bit L2 cache lines however has enough of an
adverse effect on DRAM bandwidth to basically wreck the display output
when using a RAM-backed framebuffer.

Though, seems kinda lame though to be using the whole Artix-7 just for a
single CPU core.

....

Re: Getting started with MRISC32

<spn93u$pjh$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22341&group=comp.arch#22341

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sun, 19 Dec 2021 13:38:22 +0100
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <spn93u$pjh$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 19 Dec 2021 12:38:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="753ede66e0e7aca579d9b44103d22a83";
logging-data="26225"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lZFgatdzwhwtpNnaRJyhTrK4saq7QGD8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:/izYWS5eIspG1fevJ9hCHSjrMDY=
In-Reply-To: <spkpl9$6s0$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Sun, 19 Dec 2021 12:38 UTC

On 18/12/2021 15:02, Marcus wrote:
> On 2021-12-18, Thomas Koenig wrote:
>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>> Hi!
>>>
>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>> simulator now run on the "big three"). Here's a quick tutorial for
>>> getting started:
>>>
>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>
>> Looks quite interesting.
>>
>> Do you have any plans to also implement double precision?
>> This would be needed to run my favorite programming language
>> and compiler :-)
>>
>
> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>
> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> register should be able to hold any supported data type. Since registers
> are 32 bits wide (same for vector register elements), no data type that
> is larger than 32 bits is supported by the architecture. Not memory
> addresses, not integers, not floating-point values.
>
> This is a very conscious decision (to avoid different register and
> bus/port widths etc), and the problem with double-precision floating-
> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>
> That said I believe that many languages would still work, but with quite
> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> the MRISC32 port of GCC - but it's slow.
>
> /Marcus

I don't know what your target applications are, but there are quite a
number of microcontrollers that have single-precision floating point
hardware but not double-precision. SP is enough for a lot of work - it
is accurate enough for most cases where you are measuring or controlling
real things (voltages, currents, motor speeds, etc.). The limitations
come in if you are doing a lot of calculations, as errors can build up.

Certainly there is no problem using gcc with hardware SP and software
DP. The only challenge is to make sure your users know this, and are
careful to stick to SP unless they really need DP. (gcc has flags to
help with this, but people need to use them.)

Similarly, it's fine to have slightly sub-standard single-precision
support in hardware where you only support normal numbers - no NaNs,
infinities, denormals, or other special cases. These can be handled
either in software checks at the time (which will be omitted if the user
has "-ffast-math", which is good practice for most microcontroller work)
or using exceptions tied to emulation routines.

An alternative is to drop floating point hardware entirely, and do it
all in software - a lot of the work done by small processors has no need
for any kind of floating point and omitting it can save a lot of space
in the hardware.

Re: Getting started with MRISC32

<spo7qs$ju3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22347&group=comp.arch#22347

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sun, 19 Dec 2021 15:22:35 -0600
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <spo7qs$ju3$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spn93u$pjh$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 19 Dec 2021 21:22:36 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="75b42e13be0f9ec744f65a9d2140a83f";
logging-data="20419"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/519KkwpBLGaKH93axEae2"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.0
Cancel-Lock: sha1:6awX/o1tzl8GUVR0uvtCNlQ3kHk=
In-Reply-To: <spn93u$pjh$1@dont-email.me>
Content-Language: en-US
 by: BGB - Sun, 19 Dec 2021 21:22 UTC

On 12/19/2021 6:38 AM, David Brown wrote:
> On 18/12/2021 15:02, Marcus wrote:
>> On 2021-12-18, Thomas Koenig wrote:
>>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>>> Hi!
>>>>
>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>>> simulator now run on the "big three"). Here's a quick tutorial for
>>>> getting started:
>>>>
>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>
>>> Looks quite interesting.
>>>
>>> Do you have any plans to also implement double precision?
>>> This would be needed to run my favorite programming language
>>> and compiler :-)
>>>
>>
>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>>
>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
>> register should be able to hold any supported data type. Since registers
>> are 32 bits wide (same for vector register elements), no data type that
>> is larger than 32 bits is supported by the architecture. Not memory
>> addresses, not integers, not floating-point values.
>>
>> This is a very conscious decision (to avoid different register and
>> bus/port widths etc), and the problem with double-precision floating-
>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>>
>> That said I believe that many languages would still work, but with quite
>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
>> the MRISC32 port of GCC - but it's slow.
>>
>> /Marcus
>
> I don't know what your target applications are, but there are quite a
> number of microcontrollers that have single-precision floating point
> hardware but not double-precision. SP is enough for a lot of work - it
> is accurate enough for most cases where you are measuring or controlling
> real things (voltages, currents, motor speeds, etc.). The limitations
> come in if you are doing a lot of calculations, as errors can build up.
>

It can work, though there are a few problem areas:
'atof()', as frequently implemented, can have serious accuracy issues
when implemented using single precision;
Code which assumes that 'double' can be used to hold 52-bit integers;
....

Granted, these issues mostly depend on the software in question.

But, I can note that both Cortex-M and MicroBlaze both go the route of
having single-precision in hardware, but no double precision.

> Certainly there is no problem using gcc with hardware SP and software
> DP. The only challenge is to make sure your users know this, and are
> careful to stick to SP unless they really need DP. (gcc has flags to
> help with this, but people need to use them.)
>
> Similarly, it's fine to have slightly sub-standard single-precision
> support in hardware where you only support normal numbers - no NaNs,
> infinities, denormals, or other special cases. These can be handled
> either in software checks at the time (which will be omitted if the user
> has "-ffast-math", which is good practice for most microcontroller work)
> or using exceptions tied to emulation routines.
>

In my case, I am using double precision in hardware, but with some
slightly tweaked rules and behaviors for cost-cutting.

In computation, denormals are treated as zeroes.

Conversion operators preserve a zero and NaN/Inf exponent across
formats. Other conversions can get more wacky (in effect, it is mostly
bit-repacking with a few special cases; and partial rounding on
narrowing conversions).

To some extent, some of these non-standard rules are "set in stone" due
to cases where FP constant loading may end up being used for binary
constants; or if raw memory bit-patterns end up being shuffled though FP
converters. A "correct" conversion (as per IEEE rules) would not
necessarily produce the same patterns in the output bits.

Though, to lessen the issue, BGBCC does avoid encoding constants in
these ways if the bit pattern would land on a denormal or NaN.

The FPU is also inexact in that operations typically only operate on the
high-order bits, allowing most of what would exist below the ULP to
"fall off the bottom". Then there is also the limitation that the result
is not rounded if the result would carry across too many bits.

So, eg: 0.999999999 will not necessarily round to 1.0 if doing so would
require a carry to propagate the entire mantissa. For FADD/FSUB though
there is some hackery in place to avoid this being an issue in most
cases (mostly involving the carry-bit input for the "main adder").

For FP compare:
NaN/Inf special cases only effect FCMPEQ
It is in-effect CMPQEQ but with a NaN special case.
FCMPGT is in effect special cases of an integer compare.
It is in effect CMPQHI but with some sign-bit hackery.
00: HI
01: 1
10: 0
11: !(HI|EQ)

Then, also, there is the whole "FPU only actually does FADD/FSUB/FMUL"
thing.

....

>
> An alternative is to drop floating point hardware entirely, and do it
> all in software - a lot of the work done by small processors has no need
> for any kind of floating point and omitting it can save a lot of space
> in the hardware.
>

For microcontrollers, or small embedded processors, it can make sense.

However, software emulation is generally significantly slower than a
"bare minimum" FPU.

For example, if you try to run something like Quake with software
floating-point emulation, the performance impact is rather severe.

Re: Getting started with MRISC32

<9fa9ad44-ea4a-4d77-b26e-13cb6bbb49a7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22348&group=comp.arch#22348

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1cd:: with SMTP id t13mr10523588qtw.487.1639952217398;
Sun, 19 Dec 2021 14:16:57 -0800 (PST)
X-Received: by 2002:a9d:110:: with SMTP id 16mr9396949otu.94.1639952217063;
Sun, 19 Dec 2021 14:16:57 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 19 Dec 2021 14:16:56 -0800 (PST)
In-Reply-To: <spo7qs$ju3$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:dd48:b07a:c9e5:e58e;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:dd48:b07a:c9e5:e58e
References: <spimfs$rkc$1@dont-email.me> <spkgpf$6lj$1@newsreader4.netcologne.de>
<spkpl9$6s0$1@dont-email.me> <spn93u$pjh$1@dont-email.me> <spo7qs$ju3$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9fa9ad44-ea4a-4d77-b26e-13cb6bbb49a7n@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 19 Dec 2021 22:16:57 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 195
 by: MitchAlsup - Sun, 19 Dec 2021 22:16 UTC

On Sunday, December 19, 2021 at 3:22:39 PM UTC-6, BGB wrote:
> On 12/19/2021 6:38 AM, David Brown wrote:
> > On 18/12/2021 15:02, Marcus wrote:
> >> On 2021-12-18, Thomas Koenig wrote:
> >>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>>> Hi!
> >>>>
> >>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> >>>> simulator now run on the "big three"). Here's a quick tutorial for
> >>>> getting started:
> >>>>
> >>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
> >>>
> >>> Looks quite interesting.
> >>>
> >>> Do you have any plans to also implement double precision?
> >>> This would be needed to run my favorite programming language
> >>> and compiler :-)
> >>>
> >>
> >> Kind of, if you count https://github.com/mbitsnbites/mrisc64
> >>
> >> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> >> register should be able to hold any supported data type. Since registers
> >> are 32 bits wide (same for vector register elements), no data type that
> >> is larger than 32 bits is supported by the architecture. Not memory
> >> addresses, not integers, not floating-point values.
> >>
> >> This is a very conscious decision (to avoid different register and
> >> bus/port widths etc), and the problem with double-precision floating-
> >> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
> >>
> >> That said I believe that many languages would still work, but with quite
> >> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> >> the MRISC32 port of GCC - but it's slow.
> >>
> >> /Marcus
> >
> > I don't know what your target applications are, but there are quite a
> > number of microcontrollers that have single-precision floating point
> > hardware but not double-precision. SP is enough for a lot of work - it
> > is accurate enough for most cases where you are measuring or controlling
> > real things (voltages, currents, motor speeds, etc.). The limitations
> > come in if you are doing a lot of calculations, as errors can build up.
> >
> It can work, though there are a few problem areas:
> 'atof()', as frequently implemented, can have serious accuracy issues
> when implemented using single precision;
> Code which assumes that 'double' can be used to hold 52-bit integers;
> ...
>
> Granted, these issues mostly depend on the software in question.
>
> But, I can note that both Cortex-M and MicroBlaze both go the route of
> having single-precision in hardware, but no double precision.
> > Certainly there is no problem using gcc with hardware SP and software
> > DP. The only challenge is to make sure your users know this, and are
> > careful to stick to SP unless they really need DP. (gcc has flags to
> > help with this, but people need to use them.)
> >
> > Similarly, it's fine to have slightly sub-standard single-precision
> > support in hardware where you only support normal numbers - no NaNs,
> > infinities, denormals, or other special cases. These can be handled
> > either in software checks at the time (which will be omitted if the user
> > has "-ffast-math", which is good practice for most microcontroller work)
> > or using exceptions tied to emulation routines.
> >
> In my case, I am using double precision in hardware, but with some
> slightly tweaked rules and behaviors for cost-cutting.
>
> In computation, denormals are treated as zeroes.
>
> Conversion operators preserve a zero and NaN/Inf exponent across
> formats. Other conversions can get more wacky (in effect, it is mostly
> bit-repacking with a few special cases; and partial rounding on
> narrowing conversions).
>
> To some extent, some of these non-standard rules are "set in stone" due
> to cases where FP constant loading may end up being used for binary
> constants; or if raw memory bit-patterns end up being shuffled though FP
> converters. A "correct" conversion (as per IEEE rules) would not
> necessarily produce the same patterns in the output bits.
>
> Though, to lessen the issue, BGBCC does avoid encoding constants in
> these ways if the bit pattern would land on a denormal or NaN.
>
>
> The FPU is also inexact in that operations typically only operate on the
> high-order bits, allowing most of what would exist below the ULP to
> "fall off the bottom". Then there is also the limitation that the result
> is not rounded if the result would carry across too many bits.
>
> So, eg: 0.999999999 will not necessarily round to 1.0 if doing so would
> require a carry to propagate the entire mantissa. For FADD/FSUB though
> there is some hackery in place to avoid this being an issue in most
> cases (mostly involving the carry-bit input for the "main adder").
>
>
> For FP compare:
> NaN/Inf special cases only effect FCMPEQ
> It is in-effect CMPQEQ but with a NaN special case.
> FCMPGT is in effect special cases of an integer compare.
> It is in effect CMPQHI but with some sign-bit hackery.
> 00: HI
> 01: 1
> 10: 0
> 11: !(HI|EQ)
>
-----------------------------------------------------------------------------------------------------------
<
One of the reasons I like combined Int+FP registers is that FP compare
is <essentially> an integer operation ! and Integer compare can share
about 93% of the gates ! That is if you implemented integer compare
and counted the gates, you can implement FP compare for 7% more
gates.
<
Integer compare to 0 is basically looking for fields of 1s and 0s and with
consideration of the sign bit.
<
FP compare to 0.0 is exactly the same--but there are 2 fields (exponent and
fraction) rather than just one; and of course, there is still the sign bit.
<
So you organize the gates such that you look for the fraction to be
all 1s or all 0s, the exponent to be all 1s or all 0s. Then you calculate
{F1, F0, E1, E0, S} in true and complement form (3 gates of delay) and
we have 10-bits of input to 1 more gate-delay of logic that stitches
all of the various integer and FP situations:
<
Integer: { I==0, I!=0, I>0, I>=0, I<0, I<=0, I==NEGMAX }
<
FP { FPinf, FPfinite, FPnan, FP==0, FP!=0, FPdenorm, FPnorm,
.........FP<0, FP<=0, FP>0, FP>=0, FP==±0 }
<
You then run these signals into a 1 of 32 multiplexor indexed by
bits from the compare instruction, and out pops "taken". 5-total
gates of delay from arrival of operand to taken.
<
68 individual logic gates drive the multiplexer, and the multiplexer
contains 95 gates total. So, FP added 11 gates to the entire compare
to zero calculation. 11/(68+95) = 6.7% adder to the unit.
<
Now, if you consider than My 66000 ISA also has a Branch-on-Bit
instruction, and notice that this requires a 1 of 64 multiplexer, and
we share this multiplexer with the above logic, the Branch on
comparison with Zero, the additional gates to do FP drops into the
3% range.
<
-----------------------------------------------------------------------------------------------------------
<
The argument against doing it this way is that this compare has such
a small gate count it does not matter if you share it or not in the large
scheme of things.
<
> Then, also, there is the whole "FPU only actually does FADD/FSUB/FMUL"
> thing.
>
> ...
> >
> > An alternative is to drop floating point hardware entirely, and do it
> > all in software - a lot of the work done by small processors has no need
> > for any kind of floating point and omitting it can save a lot of space
> > in the hardware.
> >
> For microcontrollers, or small embedded processors, it can make sense.
>
> However, software emulation is generally significantly slower than a
> "bare minimum" FPU.
>
> For example, if you try to run something like Quake with software
> floating-point emulation, the performance impact is rather severe.

Re: Getting started with MRISC32

<42382715-8824-41ff-8440-f0e11aad247fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22349&group=comp.arch#22349

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1652:: with SMTP id y18mr5522112qtj.63.1639969924532;
Sun, 19 Dec 2021 19:12:04 -0800 (PST)
X-Received: by 2002:a05:6830:2019:: with SMTP id e25mr10425479otp.96.1639969924234;
Sun, 19 Dec 2021 19:12:04 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 19 Dec 2021 19:12:04 -0800 (PST)
In-Reply-To: <splbmo$144$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:717c:2f39:86e2:b07d;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:717c:2f39:86e2:b07d
References: <spimfs$rkc$1@dont-email.me> <spkgpf$6lj$1@newsreader4.netcologne.de>
<spkpl9$6s0$1@dont-email.me> <spl2im$258$1@dont-email.me> <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
<splbmo$144$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <42382715-8824-41ff-8440-f0e11aad247fn@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 20 Dec 2021 03:12:04 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 107
 by: MitchAlsup - Mon, 20 Dec 2021 03:12 UTC

On Saturday, December 18, 2021 at 1:10:19 PM UTC-6, Marcus wrote:
> On 2021-12-18, MitchAlsup wrote:
> > On Saturday, December 18, 2021 at 10:34:33 AM UTC-6, BGB wrote:
> >> On 12/18/2021 8:02 AM, Marcus wrote:
> >>> On 2021-12-18, Thomas Koenig wrote:
> >>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>>>> Hi!
> >>>>>
> >>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> >>>>> simulator now run on the "big three"). Here's a quick tutorial for
> >>>>> getting started:
> >>>>>
> >>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
> >>>>
> >>>> Looks quite interesting.
> >>>>
> >>>> Do you have any plans to also implement double precision?
> >>>> This would be needed to run my favorite programming language
> >>>> and compiler :-)
> >>>>
> >>>
> >>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
> >>>
> >>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
> >>> register should be able to hold any supported data type. Since registers
> >>> are 32 bits wide (same for vector register elements), no data type that
> >>> is larger than 32 bits is supported by the architecture. Not memory
> >>> addresses, not integers, not floating-point values.
> >>>
> >>> This is a very conscious decision (to avoid different register and
> >>> bus/port widths etc), and the problem with double-precision floating-
> >>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
> >>>
> >>> That said I believe that many languages would still work, but with quite
> >>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
> >>> the MRISC32 port of GCC - but it's slow.
> >>>
> >> If you have enough register ports, it could make sense to do double
> >> precision via register pairs. Granted, this option doesn't make much
> >> sense unless the cores are superscalar or VLIW.
> > <
> > Allow me to argue that 48-years of observations have proven this
> > philosophy "wanting" at best. It causes massive consternations in
> > the register allocator of compilers.
> Agreed.
> > <
> > So, what can be done?
> > <
> > In a first iteration of my GPU ISA I had an instruction called DBLE.
> > DBLE supplied register fields and the following instruction supplies
> > more registers and the OpCode (which now pertains to a double
> > width calculation).
> > <
> > In the case of MRISC the best alternative is simply to instantiate
> > a 64-bit version MRISC64.
> Agreed.
>
> >>
> >> [snip]
> >>
>
> I decided quite early on that I wanted a better solution to FP &
> SIMD/Vector than the architectures that I had worked with before. I
> investigated various models:
>
> * Split INT/FP reg files (68k, x86/x87, MIPS, RISC-V, ...).
> * Split INT/SIMD(FP) reg files (x86/SIMD, AArch64).
> * Register pairs (88k, and some other that I can't remember).
>
> None of them really appealed to me. Then I came across Cray, and it was
> like "Ok, that's so obvious!". So I decided that FP & INT should go in
> the same registers, and for 64-bit FP you need a 64-bit arch (like
> Cray, kind of - it didn't have 64-bit address registers, which would
> have been an exaggeration at the time).
<
Bringing this back up for a different point of view:
<
I was thinking about how VVM works to separate the width and depth
of a vector of computation so that it is expressed naturally as it is in many
languages--you know--DO loops.
<
This thought train led back around to SIMD--when it occurred to me that
VVM is simply SIMD at cache access width !! and with vector chaining
around the loop ! and without creating artificial 2^n boundaries. A loop of
7 is just as efficient (for the work performed) as a loop of 8.
<
And you get all of this without blowing up the OpCode space encoding.
And without the compiler having to jump through hoops (analyses)
filtering out the loops which don't fit the HW from those that do.
<
You needeth not SIMD registers, vector registers, and you sacrifice not
the precision of exceptions.
<
>
> OTOH I wasn't ready to do a 64-bit architecture when I started out with
> my ISA (I'm still learning, and I wanted to ensure that things would go
> smoothly with an FPGA implementation), so I went with a 32-bit architecture.
>
> Being a 32-bit ISA, MRISC32 isn't going to cut it for scientific
> workloads, but there are plenty of applications where 32 bits are good
> enough, and where single precision FP is the norm (no matter how you
> look at it, 32-bit provides twice the bandwidth compared to 64-bit, and
> for most applications where you know what data ranges you're dealing
> with, binary32 is enough).
>
> ...and then there's MRISC64. :-)
>
> /Marcus

Re: Getting started with MRISC32

<spph77$in4$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22350&group=comp.arch#22350

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2a0a-a540-2738-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Mon, 20 Dec 2021 09:08:55 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spph77$in4$1@newsreader4.netcologne.de>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spl2im$258$1@dont-email.me>
<d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
<splbmo$144$1@dont-email.me>
<42382715-8824-41ff-8440-f0e11aad247fn@googlegroups.com>
Injection-Date: Mon, 20 Dec 2021 09:08:55 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2a0a-a540-2738-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2a0a:a540:2738:0:7285:c2ff:fe6c:992d";
logging-data="19172"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Mon, 20 Dec 2021 09:08 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:

> This thought train led back around to SIMD--when it occurred to me that
> VVM is simply SIMD at cache access width !! and with vector chaining
> around the loop ! and without creating artificial 2^n boundaries. A loop of
> 7 is just as efficient (for the work performed) as a loop of 8.

Yes indeed.

I would also expect (on a microarchitectural level) that it
should be possible to implement VVM where SIMD is employed on the
individual reservation stations, so a 4-wide VVM implementation
could match AVX 2, with the possible exception of

><
> And you get all of this without blowing up the OpCode space encoding.
> And without the compiler having to jump through hoops (analyses)
> filtering out the loops which don't fit the HW from those that do.
><
> You needeth not SIMD registers, vector registers, and you sacrifice not
> the precision of exceptions.

.... precise exceptions, not sure abou those.

Re: Getting started with MRISC32

<sppo66$fj9$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22351&group=comp.arch#22351

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Mon, 20 Dec 2021 12:07:49 +0100
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <sppo66$fj9$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spn93u$pjh$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 20 Dec 2021 11:07:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="02636594322a58b9cbe47565ce499ce3";
logging-data="15977"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18v9n+IFWnwiLFEy12cJE6hOyfwJej+V+4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:IuiRULhUXTXM4lFSqLnhodAiQFc=
In-Reply-To: <spn93u$pjh$1@dont-email.me>
Content-Language: en-US
 by: Marcus - Mon, 20 Dec 2021 11:07 UTC

On 2021-12-19, David Brown wrote:
> On 18/12/2021 15:02, Marcus wrote:
>> On 2021-12-18, Thomas Koenig wrote:
>>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>>> Hi!
>>>>
>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>>> simulator now run on the "big three"). Here's a quick tutorial for
>>>> getting started:
>>>>
>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>
>>> Looks quite interesting.
>>>
>>> Do you have any plans to also implement double precision?
>>> This would be needed to run my favorite programming language
>>> and compiler :-)
>>>
>>
>> Kind of, if you count https://github.com/mbitsnbites/mrisc64
>>
>> ...but MRISC32 will not get DP FP, as the main philosophy is that any
>> register should be able to hold any supported data type. Since registers
>> are 32 bits wide (same for vector register elements), no data type that
>> is larger than 32 bits is supported by the architecture. Not memory
>> addresses, not integers, not floating-point values.
>>
>> This is a very conscious decision (to avoid different register and
>> bus/port widths etc), and the problem with double-precision floating-
>> point is naturally solved in a 64-bit version of the ISA (i.e. MRISC64).
>>
>> That said I believe that many languages would still work, but with quite
>> restricted performance for 64-bit FP. E.g. C/C++ "double" works fine in
>> the MRISC32 port of GCC - but it's slow.
>>
>> /Marcus
>
> I don't know what your target applications are, but there are quite a
> number of microcontrollers that have single-precision floating point
> hardware but not double-precision. SP is enough for a lot of work - it
> is accurate enough for most cases where you are measuring or controlling
> real things (voltages, currents, motor speeds, etc.). The limitations
> come in if you are doing a lot of calculations, as errors can build up.
>

It's also quite common in DSP space to support SP in HW but not DP.

Most applications that deal with real time(ish) data processing are fine
with SP instead of DP. This includes DSP, media processing, video
codecs, audio analysis and synthesis, neural network inference (which
can go even lower, to 16 or even 8 bits), games, 3D visualization,
VR/AR, physics simulation, etc. etc.

In these kind of applications you typically want to maximize data
throughput, as that maps more or less directly to quality, resolution,
immersion, etc.

> Certainly there is no problem using gcc with hardware SP and software
> DP. The only challenge is to make sure your users know this, and are
> careful to stick to SP unless they really need DP. (gcc has flags to
> help with this, but people need to use them.)

For data bound processing on CPU:s with HW support for both SP and DP,
SP usually gives you a performance advantage of close to 2x. On CPU:s
without HW DP support the gain is obviously even higher. In any event,
developers of these kind of applications are usually quite aware of the
implications of using different floating-point precisions. If not, it
probably does not matter much (and even SW DP could be OK).

>
> Similarly, it's fine to have slightly sub-standard single-precision
> support in hardware where you only support normal numbers - no NaNs,
> infinities, denormals, or other special cases. These can be handled
> either in software checks at the time (which will be omitted if the user
> has "-ffast-math", which is good practice for most microcontroller work)
> or using exceptions tied to emulation routines.
>
>
> An alternative is to drop floating point hardware entirely, and do it
> all in software - a lot of the work done by small processors has no need
> for any kind of floating point and omitting it can save a lot of space
> in the hardware.
>

Well, "microcontroller" is not the main target of MRISC32, although such
a configuration is perfectly doable (the floating-point architecture
module is optional). With its vector capabilities it is more set up to
be a data processing workhorse. Granted, the 32-bit nature of the ISA
makes it quite niche (high data throughput /and/ restricted address
space), so in terms of generality it sits somewhere between a DSP and a
32-bit ARMv7, I guess.

Then again, I really consider it to be a proof-of-concept architecture
until I get around to do the full 64-bit version.

/Marcus

Re: Getting started with MRISC32

<spqiom$q48$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22355&group=comp.arch#22355

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Mon, 20 Dec 2021 12:41:24 -0600
Organization: A noiseless patient Spider
Lines: 145
Message-ID: <spqiom$q48$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<spkgpf$6lj$1@newsreader4.netcologne.de> <spkpl9$6s0$1@dont-email.me>
<spl2im$258$1@dont-email.me>
<d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
<splbmo$144$1@dont-email.me>
<42382715-8824-41ff-8440-f0e11aad247fn@googlegroups.com>
<spph77$in4$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 20 Dec 2021 18:41:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4eda334590fc4facd3e6a5efde41cced";
logging-data="26760"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/07uhdWl9vCW4qbvI5XrzT"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.0
Cancel-Lock: sha1:k3MQWPoouEfJnV8ai1YQkP8Ocw8=
In-Reply-To: <spph77$in4$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: BGB - Mon, 20 Dec 2021 18:41 UTC

On 12/20/2021 3:08 AM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> This thought train led back around to SIMD--when it occurred to me that
>> VVM is simply SIMD at cache access width !! and with vector chaining
>> around the loop ! and without creating artificial 2^n boundaries. A loop of
>> 7 is just as efficient (for the work performed) as a loop of 8.
>
> Yes indeed.
>
> I would also expect (on a microarchitectural level) that it
> should be possible to implement VVM where SIMD is employed on the
> individual reservation stations, so a 4-wide VVM implementation
> could match AVX 2, with the possible exception of
>

It is less obvious how I would do it in my case; it uses a fairly naive
staged pipeline:
PF IF ID1 ID2 EX1 EX2 EX3 WB

There are 3 lanes, each can execute one instruction. First lane is "do
anything", and the other two lanes are increasingly restricted.

Lane 1: Anything
Lane 2: Most ops
Excludes Mem and Branch;
Allows FPU if Lane 1 is not also FPU.
Not usable if Lane 1 is a 128-bit op.
Lane 3: Mostly does ALU, Shift, and 'Conv' ops.
Not usable if Lane 1 is a Mem, Mac, or 128-bit.

Some encodings span across multiple lanes in the decoder, these
instructions may not be used in bundled forms. This would include SIMD
ops. Some other operations use Lane 3 as a source of spare register
ports (Natively, each lane has 2R+1W, 64-bit).

The implementation of SIMD takes 2 forms:
Packed integer, basically handled as an ALU op with hacked carry
propagation (splits the register into 16 or 32 bit pieces). There are no
Packed Byte ops, but there are Packed Convert ops.

Packed FPU ops:
The FPU stalls the main pipeline and then internally feed each element
through the FADD/FMUL units, pipelined at 1 element per cycle.

This works out faster than using scalar ops, mostly because the internal
latency results in a pipeline stall for scalar ops. As-is, the cost of a
SIMD op is only slightly higher than a scalar op.

Dedicated single precision ops could have lower latency though, and
could potentially fit into the EX pipeline stages directly, but I don't
have these yet. Apart from Quake and similar, FPU ops aren't used
heavily enough to make a strong use-case.

These would likely take one of two possible forms:
Scalar op in the Double format, but with reduced range and precision;
Reused special case of the 2x Single SIMD ops.
Possible had already been specified for these via Op64 encodings with
special rounding modes.

Staying with the Double format for these ops mostly avoids a need for
significant compiler/ABI changes to use it.

The 2x Single case would "magically appear" if I added a faster
alternate route for 2x Single SIMD.

There is not currently any form of microcode.
It is possible, but haven't encountered a "sufficiently compelling"
use-case yet. Generally it has been "easier" to handle cases which
"could be" microcoded via the use of library calls.

>> <
>> And you get all of this without blowing up the OpCode space encoding.
>> And without the compiler having to jump through hoops (analyses)
>> filtering out the loops which don't fit the HW from those that do.
>> <
>> You needeth not SIMD registers, vector registers, and you sacrifice not
>> the precision of exceptions.
>
> ... precise exceptions, not sure abou those.

Making exceptions work correctly is right up there with "things that are
a total PITA".

When implementing a core:
Making memory fast and maintaining memory consistency;
Making interrupts / exceptions work reliably;
...

Are probably some of the main "hard parts".
Then, there are the usual "recurring issues", like "well, I poked at
this little thing over here, and synthesis/timing lost its crap...".

Meanwhile, many people sort of obsess endlessly on overly superficial
definitions of complexity, like how many "instructions" exist in the ISA
listing. I have noted that this actually has a relatively minor effect.

I noted when writing a RISC-V decoder, that I much prefer my approach to
the ISA encoding space layout. My approach fits more nicely into
"casez()" blocks in Verilog, whereas RISC-V doesn't fit nearly so nicely
into casez blocks. Also the way it encodes immediate values is like
something a dog chewed up, ...

Granted, my ISA is still a fair bit bigger than RISC-V.

In terms of the internal logic, I am still mostly using a scheme where
each instruction is decoded as:
6 bit major opcode / unit;
6 bit control / sub-opcode.
6 more bits which effect pipeline and predication.
3b: How the instruction maps to the pipeline (eg, multi-lane ops);
3b: How the instruction is predicated.
4x7 bits, Register IDs: Rm, Ro, Rp, Rn;
33 bits: Immediate.

Then the decoder maps the instructions onto the pipeline, assuming it to
be an allowed configuration (the Verilog implementation doesn't yet have
an "Oh crap, We can't do this!" case, but this may be needed later if
WEX6W/SMT or asymmetric multi-core or similar gets implemented, *).

*: Say, I could consider smaller cores which only run a RISC style ISA.
Likely either BJX2 Fix32 or RV64I, maybe Dual ISA as this shouldn't
significantly effect the cost of the core (it would switch out the
decoder based on the current mode). TBD.

For stuff routed through the ALU, this has gotten a bit messy, but most
other things still work OK.

Mapping this internal form directly to the instruction encoding seems
"less ideal" mostly because it constrains what units exist and how they
behave (this may change over time, or make sense to differ between
implementations).

Also, a lot more of the encoding variability has to do with how the
registers or immediate values are handled, than about the units used to
express the operation (one may end up with a lot of encodings which
drive the same unit, just with different inputs).

....

Re: Getting started with MRISC32

<2f046e7f-0f52-4cb7-973f-c22e9120e394n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22356&group=comp.arch#22356

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2996:: with SMTP id r22mr10547386qkp.485.1640026780439;
Mon, 20 Dec 2021 10:59:40 -0800 (PST)
X-Received: by 2002:a9d:4f0b:: with SMTP id d11mr12604495otl.227.1640026780175;
Mon, 20 Dec 2021 10:59:40 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 20 Dec 2021 10:59:39 -0800 (PST)
In-Reply-To: <spqiom$q48$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:e1a7:8791:699c:c121;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:e1a7:8791:699c:c121
References: <spimfs$rkc$1@dont-email.me> <spkgpf$6lj$1@newsreader4.netcologne.de>
<spkpl9$6s0$1@dont-email.me> <spl2im$258$1@dont-email.me> <d33b9dfa-367e-4d53-8a4e-1d6381ea6dban@googlegroups.com>
<splbmo$144$1@dont-email.me> <42382715-8824-41ff-8440-f0e11aad247fn@googlegroups.com>
<spph77$in4$1@newsreader4.netcologne.de> <spqiom$q48$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2f046e7f-0f52-4cb7-973f-c22e9120e394n@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 20 Dec 2021 18:59:40 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 121
 by: MitchAlsup - Mon, 20 Dec 2021 18:59 UTC

On Monday, December 20, 2021 at 12:41:29 PM UTC-6, BGB wrote:
> On 12/20/2021 3:08 AM, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> >
> >> This thought train led back around to SIMD--when it occurred to me that
> >> VVM is simply SIMD at cache access width !! and with vector chaining
> >> around the loop ! and without creating artificial 2^n boundaries. A loop of
> >> 7 is just as efficient (for the work performed) as a loop of 8.
> >
> > Yes indeed.
> >
> > I would also expect (on a microarchitectural level) that it
> > should be possible to implement VVM where SIMD is employed on the
> > individual reservation stations, so a 4-wide VVM implementation
> > could match AVX 2, with the possible exception of
<
A medium-end machine might perform VVMs that way.
I higher end machine would definitely want multiple lanes of calculation/
memory access/... to be performed every cycle.
<
> >
> It is less obvious how I would do it in my case; it uses a fairly naive
> staged pipeline:
> PF IF ID1 ID2 EX1 EX2 EX3 WB
<
All my designs use a similarly crafted pipeline (possibly plural)
>
> There are 3 lanes, each can execute one instruction. First lane is "do
> anything", and the other two lanes are increasingly restricted.
>
> Lane 1: Anything
> Lane 2: Most ops
> Excludes Mem and Branch;
> Allows FPU if Lane 1 is not also FPU.
> Not usable if Lane 1 is a 128-bit op.
> Lane 3: Mostly does ALU, Shift, and 'Conv' ops.
> Not usable if Lane 1 is a Mem, Mac, or 128-bit.
>
> Some encodings span across multiple lanes in the decoder, these
> instructions may not be used in bundled forms. This would include SIMD
> ops. Some other operations use Lane 3 as a source of spare register
> ports (Natively, each lane has 2R+1W, 64-bit).
>
Your implementations are limited to FPGA (IIRC); but if you got "more resources"
you too could consider building a SIMD VVM loop around the cache access width
and somewhat far away from the "main" pipeline.
<snip>
> >> <
> >> And you get all of this without blowing up the OpCode space encoding.
> >> And without the compiler having to jump through hoops (analyses)
> >> filtering out the loops which don't fit the HW from those that do.
> >> <
> >> You needeth not SIMD registers, vector registers, and you sacrifice not
> >> the precision of exceptions.
> >
> > ... precise exceptions, not sure abou those.
<
> Making exceptions work correctly is right up there with "things that are
> a total PITA".
<
And totally necessary.
>
> When implementing a core:
> Making memory fast and maintaining memory consistency;
> Making interrupts / exceptions work reliably;
Making the TLBs coherent
Making context switch take no more cycles than a FP×
> ...
>
> Are probably some of the main "hard parts".
> Then, there are the usual "recurring issues", like "well, I poked at
> this little thing over here, and synthesis/timing lost its crap...".
>
So, don't poke at that over there......
>
> Meanwhile, many people sort of obsess endlessly on overly superficial
> definitions of complexity, like how many "instructions" exist in the ISA
> listing. I have noted that this actually has a relatively minor effect.
>
> I noted when writing a RISC-V decoder, that I much prefer my approach to
> the ISA encoding space layout. My approach fits more nicely into
> "casez()" blocks in Verilog, whereas RISC-V doesn't fit nearly so nicely
> into casez blocks. Also the way it encodes immediate values is like
> something a dog chewed up, ...
>
> Granted, my ISA is still a fair bit bigger than RISC-V.
Mine is smaller and can do more......
>
>
> In terms of the internal logic, I am still mostly using a scheme where
> each instruction is decoded as:
> 6 bit major opcode / unit;
> 6 bit control / sub-opcode.
> 6 more bits which effect pipeline and predication.
> 3b: How the instruction maps to the pipeline (eg, multi-lane ops);
> 3b: How the instruction is predicated.
> 4x7 bits, Register IDs: Rm, Ro, Rp, Rn;
> 33 bits: Immediate.
<
I use the 6-bit Major OpCode to choose which of the 6 formats to "decode"
1) 16-bit immediate
2) 1-register operand
3) 2-register operand
4) 3-register operand
5) Memory Reference
6) a pair of 6-bit immediates (Shifts and bit fields)
The register fields are common across the entire decoding space.
>

Re: Getting started with MRISC32

<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22451&group=comp.arch#22451

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:cc2:: with SMTP id 2mr10134548qvx.90.1640477267706;
Sat, 25 Dec 2021 16:07:47 -0800 (PST)
X-Received: by 2002:aca:646:: with SMTP id 67mr8923212oig.175.1640477267283;
Sat, 25 Dec 2021 16:07:47 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 25 Dec 2021 16:07:47 -0800 (PST)
In-Reply-To: <spimfs$rkc$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=60.48.14.105; posting-account=JwRkAAkAAADB2qESRxaIoL0MVeLh5Uyo
NNTP-Posting-Host: 60.48.14.105
References: <spimfs$rkc$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
Subject: Re: Getting started with MRISC32
From: othm...@gmail.com (Othman Ahmad)
Injection-Date: Sun, 26 Dec 2021 00:07:47 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 14
 by: Othman Ahmad - Sun, 26 Dec 2021 00:07 UTC

On Saturday, 18 December 2021 at 02:55:59 UTC+8, Marcus wrote:
> Hi!
>
> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
> simulator now run on the "big three"). Here's a quick tutorial for
> getting started:
>
> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>
> /Marcus
Congratulations.
YOu prove again that the open source ecosystem is getting easier to port microprocessor architectures.

I tried a few years ago, but found it still too difficult.
I resorted to simpler simulators and my own simplest assembler for SWORD32. I notice you use your GNU assembler which should make it easily to couple with other tools.

Re: Getting started with MRISC32

<sqk7d2$6vc$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22605&group=comp.arch#22605

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Thu, 30 Dec 2021 13:06:57 +0100
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <sqk7d2$6vc$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 30 Dec 2021 12:06:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6016acade3692638d873f399288fb852";
logging-data="7148"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VpBldfyo146emJlAl1NVjQ6LSKI/2bXk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:XtgfFIKDNzDl31J7fI+l1v1VodE=
In-Reply-To: <fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
Content-Language: en-US
 by: Marcus - Thu, 30 Dec 2021 12:06 UTC

On 2021-12-26, Othman Ahmad wrote:
> On Saturday, 18 December 2021 at 02:55:59 UTC+8, Marcus wrote:
>> Hi!
>>
>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>> simulator now run on the "big three"). Here's a quick tutorial for
>> getting started:
>>
>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>
>> /Marcus
> Congratulations.
> YOu prove again that the open source ecosystem is getting easier to port microprocessor architectures.

Thanks. Yes, I am a strong believer in open source. Good open source
solutions prosper and keep improving, forever, whereas closed source
solutions have limited life times and will eventually die (and they can
die for many reasons - e.g. business decisions). Thus, in the long run
you can not compete with open source.

>
> I tried a few years ago, but found it still too difficult.
> I resorted to simpler simulators and my own simplest assembler for SWORD32. I notice you use your GNU assembler which should make it easily to couple with other tools.
>

I started out with a custom assembler written from scratch in Python,
but eventually I wanted to build more complex programs (e.g. linking
together several object files, using macros, prepocessing etc), and at
that point it was much easier to just port GNU binutils. It's actually
quite easy, and you get things like ELF linking and disassembly "for
free".

The MRISC32 assembler/GAS part of binutils is ~2500 lines of C code,
whereas my own assembler was ~1500 lines of Python code (and it was a
much simpler assembler, only supporting a much earlier version of the
ISA).

/Marcus

Re: Getting started with MRISC32

<sqlvr2$1v4$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22636&group=comp.arch#22636

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Thu, 30 Dec 2021 20:10:10 -0800
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <sqlvr2$1v4$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
<sqk7d2$6vc$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 31 Dec 2021 04:10:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="38239b0b0c4ef08355a77f5f6d42268a";
logging-data="2020"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LvK5MYHcS7/wzBBg0puxo"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:wQ+5ZxneZnshQI/db0zAqSmENso=
In-Reply-To: <sqk7d2$6vc$1@dont-email.me>
Content-Language: en-US
 by: Ivan Godard - Fri, 31 Dec 2021 04:10 UTC

On 12/30/2021 4:06 AM, Marcus wrote:
> On 2021-12-26, Othman Ahmad wrote:
>> On Saturday, 18 December 2021 at 02:55:59 UTC+8, Marcus wrote:
>>> Hi!
>>>
>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>> simulator now run on the "big three"). Here's a quick tutorial for
>>> getting started:
>>>
>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>
>>> /Marcus
>> Congratulations.
>> YOu prove again that the open source ecosystem is getting easier to
>> port microprocessor architectures.
>
> Thanks. Yes, I am a strong believer in open source. Good open source
> solutions prosper and keep improving, forever, whereas closed source
> solutions have limited life times and will eventually die (and they can
> die for many reasons - e.g. business decisions). Thus, in the long run
> you can not compete with open source.

Do you feel that implies that open source solutions are necessarily
*better* than the solutions they have overcome, or are just cheaper in
the short run?

Re: Getting started with MRISC32

<164096126460.26094.3289422083276434150@media.vsta.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22653&group=comp.arch#22653

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Fri, 31 Dec 2021 06:34:24 -0800
Lines: 21
Message-ID: <164096126460.26094.3289422083276434150@media.vsta.org>
References: <sqlvr2$1v4$1@dont-email.me> <spimfs$rkc$1@dont-email.me> <fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com> <sqk7d2$6vc$1@dont-email.me>
X-Trace: individual.net NyrzZNK3TX4c2kTv3awQBAU/ep6LuKY3jr2iVF1lZ2E0MbS0Nn
X-Orig-Path: media
Cancel-Lock: sha1:bGls+erfusiwR43+c5c+UwM8Iak=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Fri, 31 Dec 2021 14:34 UTC

Ivan Godard <ivan@millcomputing.com> writes:
> Do you feel that implies that open source solutions are necessarily
> *better* than the solutions they have overcome, or are just cheaper in
> the short run?

The "many eyes" phenomenon has benefited many of the widely used open source
projects.

There's also the "personal options" aspect. An example is Linux's kernel
policy to only let root listen on ports below 1024 (set aside the capabilties
system, which came later than this example). It was perfectly reasonable to
add a sysctl node "privport", thus letting our deployment write it to a lower
number.

There are other way to fry that fish. The point is, there's a broad,
fundamental class of solutions available _only_ if you start from open
source.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: Getting started with MRISC32

<sqnjad$gs6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22664&group=comp.arch#22664

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Fri, 31 Dec 2021 12:48:42 -0600
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <sqnjad$gs6$1@dont-email.me>
References: <sqlvr2$1v4$1@dont-email.me> <spimfs$rkc$1@dont-email.me>
<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
<sqk7d2$6vc$1@dont-email.me>
<164096126460.26094.3289422083276434150@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 31 Dec 2021 18:48:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4f77bb898055d3f681c614877a29f57d";
logging-data="17286"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0ZhsWckVcAI5yBhLeavvU"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Cancel-Lock: sha1:MJRb6/xsZVMNmEpdRt0hyroR/Zg=
In-Reply-To: <164096126460.26094.3289422083276434150@media.vsta.org>
Content-Language: en-US
 by: BGB - Fri, 31 Dec 2021 18:48 UTC

On 12/31/2021 8:34 AM, Andy Valencia wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> Do you feel that implies that open source solutions are necessarily
>> *better* than the solutions they have overcome, or are just cheaper in
>> the short run?
>
> The "many eyes" phenomenon has benefited many of the widely used open source
> projects.
>
> There's also the "personal options" aspect. An example is Linux's kernel
> policy to only let root listen on ports below 1024 (set aside the capabilties
> system, which came later than this example). It was perfectly reasonable to
> add a sysctl node "privport", thus letting our deployment write it to a lower
> number.
>

So, you need to run ones' web/ftp/... servers as 'root'? This would seem
to cause a bigger security risk than it would prevent (such as in the
case where a server is compromised via a buffer overflow or similar).

I vaguely remember though that these servers tended to have their own
dedicated user IDs (not 'root'). Though, maybe it is "root group" rather
than "root user", not looked into it too closely.

Though, yeah, OTOH we probably don't want other random programs opening
up listening ports in this area either.

> There are other way to fry that fish. The point is, there's a broad,
> fundamental class of solutions available _only_ if you start from open
> source.
>

Probably true.

In many areas, open source wins.

In terms of developer tools, general purpose utilitarian software, ...,
open source is the clear winner.

Some other non-open-source software may be OK if it is free, but there
is very little "actually costs money" software on my PC besides Windows
itself.

There are a few drawbacks though with open source:
UX often tends to be worse in open source vs proprietary software;
Things like games and similar tend to be significantly worse.

Some of the better examples of open source gaming are essentially a
glorified case of "Take the idTech engine games and replace all of the
artwork/models/... with placeholders, may or may not come up with an
original name for it."

Some are "sorta like the original, but worse in nearly every aspect"
(such as comparing Minetest with Minecraft).

Then sit around wondering about a few "WTF?!" aspects, like apparently
Minetest storing its worlds (terrain data and everything) inside of an
SQL database. Like, may be wrong, but somehow I don't necessarily think
games should be built on top of PostgreSQL or similar (*).

Generally, the "for profit" indie games tend to do better on this front
(so, it isn't really an "AAA vs everyone else" thing).

*: They can be like "Well, the SQL Database is vastly better than
dumping it all as massive ASCII CSV files". My thinking: "So, don't use
CSV files either."

This is almost an incentive to resume working on my BGBTech2 engine, as
despite it "also sucking", my stuff was at least "not that much worse".

But, also faced with the issue of "not having a job" (one can try
applying to places, but generally nothing comes of it). Not sure if any
of my projects have much profit potential, not much thus far to make me
all that optimistic.

> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

Re: Getting started with MRISC32

<sqnvk0$2ik$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22671&group=comp.arch#22671

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-eb03-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Fri, 31 Dec 2021 22:18:40 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <sqnvk0$2ik$1@newsreader4.netcologne.de>
References: <sqlvr2$1v4$1@dont-email.me> <spimfs$rkc$1@dont-email.me>
<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
<sqk7d2$6vc$1@dont-email.me>
<164096126460.26094.3289422083276434150@media.vsta.org>
<sqnjad$gs6$1@dont-email.me>
Injection-Date: Fri, 31 Dec 2021 22:18:40 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-eb03-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:eb03:0:7285:c2ff:fe6c:992d";
logging-data="2644"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Fri, 31 Dec 2021 22:18 UTC

BGB <cr88192@gmail.com> schrieb:
> On 12/31/2021 8:34 AM, Andy Valencia wrote:
>> Ivan Godard <ivan@millcomputing.com> writes:
>>> Do you feel that implies that open source solutions are necessarily
>>> *better* than the solutions they have overcome, or are just cheaper in
>>> the short run?
>>
>> The "many eyes" phenomenon has benefited many of the widely used open source
>> projects.
>>
>> There's also the "personal options" aspect. An example is Linux's kernel
>> policy to only let root listen on ports below 1024 (set aside the capabilties
>> system, which came later than this example). It was perfectly reasonable to
>> add a sysctl node "privport", thus letting our deployment write it to a lower
>> number.
>>
>
> So, you need to run ones' web/ftp/... servers as 'root'?

No.

One would have to start them as root, they would bind to the port,
and then they would drop all privileges via setuid(2).

Re: Getting started with MRISC32

<164100130761.7669.2676770046608943169@media.vsta.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22673&group=comp.arch#22673

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Fri, 31 Dec 2021 17:41:47 -0800
Lines: 15
Message-ID: <164100130761.7669.2676770046608943169@media.vsta.org>
References: <sqnvk0$2ik$1@newsreader4.netcologne.de> <sqlvr2$1v4$1@dont-email.me> <spimfs$rkc$1@dont-email.me> <fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com> <sqk7d2$6vc$1@dont-email.me> <164096126460.26094.3289422083276434150@media.vsta.org> <sqnjad$gs6$1@dont-email.me>
X-Trace: individual.net emqgEioufagrBhBArDttpgF+qW5shOWJxMtZw9ew51e7xruyhK
X-Orig-Path: media
Cancel-Lock: sha1:YtBn/UuclQmKFTpDUXlgq4E4Jjo=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Sat, 1 Jan 2022 01:41 UTC

Thomas Koenig <tkoenig@netcologne.de> writes:
> > So, you need to run ones' web/ftp/... servers as 'root'?
> No.
> One would have to start them as root, they would bind to the port,
> and then they would drop all privileges via setuid(2).

And thus the game begins... a program with _no_ need for root has one forced
upon it by an OS dictate. It PROMISES to let its mighty powers go RSN!

I can argue either side. The point is, with open source, the decision
ultimately rests with me.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: Getting started with MRISC32

<sqq369$c4n$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22683&group=comp.arch#22683

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Getting started with MRISC32
Date: Sat, 1 Jan 2022 18:31:52 +0100
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <sqq369$c4n$1@dont-email.me>
References: <spimfs$rkc$1@dont-email.me>
<fe4ef4da-991c-4135-96e4-c344775e7cd2n@googlegroups.com>
<sqk7d2$6vc$1@dont-email.me> <sqlvr2$1v4$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 1 Jan 2022 17:31:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7f459bd6dad7740af46c98d0e5a8aaf4";
logging-data="12439"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19z/aSpa4rO4b/Oy5UxfpZ0Fu6RtLZROOo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:n6vTM6gj29mr7drNzX1AxiNS4IY=
In-Reply-To: <sqlvr2$1v4$1@dont-email.me>
Content-Language: en-US
 by: Marcus - Sat, 1 Jan 2022 17:31 UTC

On 2021-12-31, Ivan Godard wrote:
> On 12/30/2021 4:06 AM, Marcus wrote:
>> On 2021-12-26, Othman Ahmad wrote:
>>> On Saturday, 18 December 2021 at 02:55:59 UTC+8, Marcus wrote:
>>>> Hi!
>>>>
>>>> The MRISC32 ecosystem has matured somewhat (e.g. the compiler and
>>>> simulator now run on the "big three"). Here's a quick tutorial for
>>>> getting started:
>>>>
>>>> https://www.bitsnbites.eu/getting-started-with-mrisc32/
>>>>
>>>> /Marcus
>>> Congratulations.
>>> YOu prove again that the open source ecosystem is getting easier to
>>> port microprocessor architectures.
>>
>> Thanks. Yes, I am a strong believer in open source. Good open source
>> solutions prosper and keep improving, forever, whereas closed source
>> solutions have limited life times and will eventually die (and they can
>> die for many reasons - e.g. business decisions). Thus, in the long run
>> you can not compete with open source.
>
> Do you feel that implies that open source solutions are necessarily
> *better* than the solutions they have overcome, or are just cheaper in
> the short run?

I should probably write a blog post about this topic, but here we go...

First off, open source solutions are not automatically better than
closed source solutions (nor is the reverse true), and there are
certainly lots of situations when closed source makes better sense
(especially from a development & business perspective). However, open
source has a lot going for it, especially in the long term...

(Here I'm mostly speaking from my personal experiences - I have worked
extensively with both closed source and open source products, both as
a developer and as a user).

*Peer review* - Open source can get orders of magnitude more review than
closed source. This has a positive impact on quality. There's also a
subtle psychological effect: When my source code is made public for
_everyone_ to see (including industry experts, potential future
employers, friends, former/future colleagues, etc), I instinctively care
more about how it looks (style, documentation), and that it's correct
(i.e. avoid embarrassing mistakes). In a closed source product the
incentive is strong to just close the ticket in time for this sprint.

*User base* - As an open source product is free for all, it naturally
attracts a larger user base than a non-free product (given all else
being equal). A larger user base comes with lots of benefits, including
more testing (proven-in-use), more requirements (now that it can do A,
it would be nice if it could also do B), bug reports and fixes, etc.

*Platform coverage* - A closed source product will typically target the
few different platforms (operating systems, architectures, boards, ...)
that give the highest ROI and/or that the developer has access to. Open
source products on the other hand encourage wider platform support (if
an enthusiast user wants the product to support exotic platform X, it is
entirely possible to make it so).

*Time is not an issue* - Closed source products are typically developed
under time pressure, often targeting short term business goals. Open
source products on the other hand can mature in a pace that encourages
long term goals and high quality standards.

*Life expectancy* - A closed source product is at the mercy of market
forces. If a product does not fit with the market plan of the governing
company, or if the company goes bankrupt, it will pass into oblivion
and die. An open source product has eternal life. The number of man-
hours built in to a long lived open source product is hard to beat by a
closed source product.

I also have a number of real-life examples of these claims, but I'll
save that for another time.

/Marcus

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor