On 2022-03-06, Tim Rentsch wrote:
> Marcus <m.delete@this.bitsnbites.eu> writes:
>
>> On 2022-01-07, Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Marcus wrote:
>>>>
>>>>> On 2021-12-30, EricP wrote:
>>>>>
>>>>>> C,C++ and a bunch of languages explicitly define booleans as 0 or 1
>>>>>> so this definition won't be optimal for those languages.
>>>>>> VAX Fortran used 0,-1 for LOGICAL but I don't know if that
>>>>>> was defined by the language or implementation dependant.
>>>>
>>>> -1 is better than 1, it can be used as a mask.
>>>>
>>>>> As a software developer I'm painfully aware of this. I decided not to
>>>>> care too much about it, though. Really, most software that relies on
>>>>> this property of C should be frowned upon. E.g. expressions like:
>>>>>
>>>>> a = b + (c == d);
>>>>>
>>>>> ...aren't really good programming practice.
>>>>
>>>> No! Please tell me it ain't so!
>>>>
>>>> I use that type of constructs [frequently ...]
>>>
>>> Totally with you on this. People who don't see the benefit of
>>> using 0/1 values instead of if/else in cases like this are stuck
>>> in an antiquated way of thinking.
>>
>> Care to elaborate? What context are we talking about here? C?
>> Machine code? Microarchitecture?
>
> Programming languages. I don't mean to include low-level
> languages that are basically just glorified assembly languages.
> Let's say at the level of C or higher.
>
>> Have a look at https://godbolt.org/z/K7ndn57T1 and feel free to
>> compare what machine code you get on different architectures for
>> the different C code snippets (spoiler alert: with modern
>> compilers there will typically be no difference at all).
>
> I take it as given that compilers of today (or even ten years ago)
> can and do generate excellent code in such cases. For the most part
> I'm not interested in what machine code is produced, except in those
> rare situations where performance is critical to what the program is
> doing (and in almost all code written, it isn't).
>
>> My point is that you should strive for writing (high level) code
>> that is as clear as possible w.r.t. the intent of the program
>> (e.g. avoid error prone constructs). [...]
>
> We agree on the principle. The question is which constructions are
> more clear? In another posting in this general thread you say this:
>
>> So, in general I do not like code that makes assumptions about the
>> integer value of a comparison result. I much rather see explicit
>> if-then-else statements,
>
> My reaction is just the opposite. Insisting on if-then-else is
> firmly stuck in the von Neumann imperative mindset. Using "logical
> values" as integers is one of the great advances in programming
> languages. APL illustrates the power of if-less programming. By
> contrast, if/else is usually harder to understand and more likely to
> be a source of error. When I'm looking at source code, I usually
> find that the more if()s there are, the more likely the code is to
> be buggy. It is the if/else, von Neumann imperative style of
> programming that was (in part) what I meant above by "antiquated
> way of thinking".

Those are all valid points, and I get what you're getting at now. I
agree that von Neumann style coding is a major blocker for proper
parallelization etc.

My reaction was mostly against the pre-antiquated coding style (80's
to 90's, I'd say), where people would write cryptic C code with the
intent of mapping to specific machine code instructions in order to
produce faster machine code. I.e. helping the (then dumb) compiler to
produce faster code. I still see similar code constructs today (e.g.
abuse of lengthy and nested ternary expressions) coming from programmers
that think that they are being clever, but really they do not know how
the compiler works and what kind of machine code is being produced.

Of course, what is more readable and less error prone is up for debate,
but my point was that it's usually better to prioritize readability
(according to some measure of choice).

>
> Please don't take any of these comments as personal. I am trying to
> express a general point of view; I don't mean to focus on any of
> your views in particular. My apologies if it came across otherwise.

NP

On Friday, December 24, 2021 at 12:17:50 PM UTC-6, MitchAlsup wrote:
> On Friday, December 24, 2021 at 11:00:14 AM UTC-6, Anton Ertl wrote:
> > I have recently (despite me) watched
> > <https://www.youtube.com/watch?v=Ii_pEXKKYUg>, where Chris Celio
> > compares some aspects RV64G, RV64GC, ARM A32, ARM A64, IA-32 and
> > AMD64. There is also a tech report <https://arxiv.org/abs/1607.02318>
> > <https://arxiv.org/pdf/1607.02318.pdf>
> >
> > In this posting I look at the different approaches taken in A64 (aka
> > Aarch64) and RV64GC:
> >
> > * RISC-V has simple instructions, e.g., with only one addressing mode
> > (reg+offset), and the base instruction set encodes each instruction
> > in 32 bits, but with the C (compressed) extension adds a 16-bit
> > encoding for the most frequent instructions.
> >
> > * A64 has fixed-length 32-bit instructions, but they can be more
> > complex: A64 has more addressing modes and additional instructions
> > like load pair and store pair; in particular, the A64 architects
> > seem to have had few concerns about the register read and write
> > ports needed per instruction; E.g., a store-pair instruction can
> > need four read ports, and a load pair instruction can need three
> > write ports (AFAIK).
> >
> > Celio argues that the instruction density of RV64GC is competetive,
> > and that the C extension is cheap to implement for a small
> > implementation.
> <
> My 66000 ISA has x86-64 instruction set density and is RISC with
> a couple of additions--large constants (immediates and displacements
> or both).
<
After compiling CoreMark benchmark for RISC-Viemfdscu and My 66000
and then counting all of the instructions. I have found that My 66000 only
contains 73% of the instructions RISC-V contains.
<
So,
My 66000 does not have the code density of x86-64 !! Sorry for the confusion.
My 66000 has the code density of RISC-V using compressed instructions !!
without having any compressed instructions !!
<
This seemed like the most appropriate place to set the record straight.