On Tuesday, October 12, 2021 at 5:47:41 PM UTC-5, BGB wrote:
> On 10/12/2021 4:46 PM, MitchAlsup wrote:
> > On Tuesday, October 12, 2021 at 1:18:42 PM UTC-5, BGB wrote:
> >> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>
> >>>> Victor Yodaiken <victor....@gmail.com> schrieb:
> >>>>
> >>>>> Can you cast a pointer to a different type? Sure.
> >>>>>
> >>>>> Can you dereference it?
> >>>>
> >>>> No.
> >>>
> >>> This statement is wrong, or at best much overstated. There are
> >>> plenty of situations where a C pointer value converted to a
> >>> different type may be safely and portably dereferenced.
> >>> Certainly that isn't always true, but it isn't always false
> >>> either.
> >>>
> >> Yeah. For some types of code it is desirable to be able to cast and
> >> dereference a pointer as whatever type matches what one wants to do with it.
> > <
> > During my career I went to so many meetings about memory referencing
> > and how this/that machine was good/bad, I stabilized my thinking about
> > referencing memory into the camp of::
> > a) memory is Inherently misaligned,
> > b) you can't do anything about making that go away,
> > c) you can make the HW capable of delivering near zero overhead to misalignment;
> > THAT: you should simply design the machine as inherently misaligned.
> > <
> > And at this point, If you create/cast a pointer to something, you CAN
> > dereference it. Whether it is profitable or not is up to the programmer.
> Granted.
>
> Nearly all access in BJX2 is misaligned-safe by default, with a few
> partial exceptions which don't significantly effect code generation for
> the most part (mostly effecting the handling of constant displacements
> and MOV.X and similar).
> >>
> >> Requiring something like, say, using "memcpy()" to mash bits from one
> >> format to another and hoping the compiler is smart and reliable enough
> >> to make this "not suck" is a crap solution, IMHO.
> > <
> > Requiring a trip through memory to get from FP-register to int-register
> > is similarly stupid !! {Note: my restrained hand, here.}
> > <
> > SIMD-register to int-register or FP-register probably remains necessary--
> > because SIMD is not the same (or similar size) as int or FP.
> Granted, but these is no way to express this in (standard) C.
> There are compiler intrinsics for this case in BGBCC.
>
> In effect, it is mostly how much extra overhead one wants to impose on
> transferring a value from one register to another.
>
> Meanwhile, the ASM programmer can make use of both integer and FP
> operations using GPRs.
>
>
> This was also a partial incentive for building dynamic typing into
> BGBCC, besides it being needed for my BS2 language: the compiler can do
> all this a lot more efficiently than leaving it up to user code.
>
> In theory, it could also allows for a fairly lightweight JavaScript FFI
> if C code can more directly access JS data and environments without
> needing an awkward and convoluted wrapper API.
>
> Even if, yeah, one probably doesn't want to use dynamic typing when
> avoidable for normal code, in my tests, the performance overhead of
> using dynamic typing is actually surprisingly modest though (as-in,
> "doesn't ruin performance quite as bad as one might intuitively expect
> given it turns pretty much every operator into a runtime call").
>
>
> Full hardware support is unlikely, but it is possible that a few special
> cases can be useful, such as a combined "Morton shuffle and Logical
> Shift Right" operator and similar, or a "Table-Switch with Unsigned
> Saturate".
>
> Say:
> ADD R4, -64, R3
> BRUSS.L 180, R3
> BRA4B .L_case_64
> BRA4B .L_case_65
> ...
> BRA4B .L_case_242
> BRA4B .L_case_243
> BRA4B .L_case_default
<
ADD R4,R3,#-64
TJMP R4,#179
.halfword L_case_64-., L_case_65-.
.......
.halfword L_case_242-.,L_case_243-.
default::
<
If all the labels are within 1024 bytes of the TJMP instruction, then the
table can be comprised of byte offsets (instead of halfword offsets, shown).
<
No-one can transfer control into the table and get anything other than a
fault.
>
> Where, any value outside the range of 0..179 goes to 180, while
> otherwise branching to (PC+Rn*4).
>
> Mostly this is because dynamically-typed runtime-support code internally
> tends to make fairly heavy use of "switch()".
>
> At present, this would be done more like:
> ADD R4, -64, R3
> CMPHI 179, R3
> BT .L_case_default
> BRA.L R3
> BRA4B .L_case_64
> BRA4B .L_case_65
> ...
> BRA4B .L_case_242
> BRA4B .L_case_243
>
Similar TJMP sequence as above.

On 2021-10-12, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Tuesday, October 12, 2021 at 4:03:29 PM UTC-5, Branimir Maksimovic wrote:
>> On 2021-10-12, MitchAlsup <Mitch...@aol.com> wrote:
>> > On Tuesday, October 12, 2021 at 8:39:58 AM UTC-5, David Brown wrote:
>> >> On 11/10/2021 20:04, Victor Yodaiken wrote:
>> >> > On Sunday, October 10, 2021 at 5:48:01 AM UTC-5, David Brown wrote:
>> >> >
>> >> >> The idea of C being a "high-level assembler" is right there in
>> >> >> section 1, "Introduction".
>> >> >>
>> >> >
>> >> > There is something about high level assembler in the introduction -
>> >> > it is a QUOTE from the C Rationale. If you honestly interpreted it as
>> >> > a claim that C was supposed to be a complete replacement for all
>> >> > assembly languages, then maybe you need new glasses.
>> >> >
>> >> I know that what you wrote was a quotation from a C Rationale document.
>> >> Clearly I did not interpret it as you suggest - you cannot complain
>> >> that I have exaggerated your writings and then do /exactly/ the same
>> >> thing yourself! The difference, however, is that I was doing so as a
>> >> criticism of your argument - you appear to be doing so as some kind of
>> >> revenge.
>> >>
>> >>
>> >> But do I take it that you agree with me that C is not a "high-level
>> >> assembly"?
>> >>
>> >> A vital characteristic of assembly, as a programming language, is that
>> >> the generated code does /exactly/ what you order, no more and no less,
>> >> without re-ordering, optimising, removing or adding anything. C is not
>> >> a language remotely like that, never has been, never will be.
>> ><
>> > You have obviously never used a good macro assembler............
>> >>
>> Macros in assembler are different, you just define macro, that's all :P
>> No surprises...
><
> Macros in assembler can perform a variety of tests to determine the sequence
> of code emitted. In the DEC assemblers, when you "call" an assembly macro,
> it pops the macro off the symbol table list. This enables an ADD macro to
> look at its parameters, and when acceptable, emit an ADD instruction.
><
> After this phase, the assembler performs code scheduling and sometimes
> peephhole optimizations.
><
> We used to use the DEC macro facility to choose between 18-bit offsets
> and loading from constant pools on the PDP-10, and what some might
> call some "heinous" stuff in the PDP-11 macro facility. I had several macros
> that were more than 100 lines of ASM long, typically producing exactly
> 1 instruction.
Oh, it's more like small compiler then assembler. I am used to x86
assemblers which are nowhere near that. Thank for info,
Branimir.

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-12, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Tuesday, October 12, 2021 at 4:19:34 PM UTC-5, victor....@gmail.com wrote:
>> On Tuesday, October 12, 2021 at 8:39:58 AM UTC-5, David Brown wrote:
>>
>> > But do I take it that you agree with me that C is not a "high-level
>> > assembly"?
>> The first paragraph of the paper ---- The C programming language [33] is the
>> first, and, so far,only widely successful programming language that provides
>> operating system developers with a high-level language alternative to
>> assembler (compare to [42]). C’s success was predicated on its design: a
>> small language, close to the machine yet with a great deal of flexibility
>> for experienced programmers. The Rationale for the C standard [9] cited C’s
>> capability to function as a "high-level assembler" and explained that"many
>> operations are defined to be how the target machine’s hardware does it
>> rather than by a general abstract rule" but C also has traditional
>> attributes of an ALGOL style programming language. -----
>>
>> Note, among other phrases: 1) a high-level language alternative to assembler
>> 2) C also has traditional attributes of an ALGOL style programming language.
> 2.1) without nesting of {blocks, subroutines, data} 2.2) without strict
> typing 2.3) without allocating dynamic arrays on the stack

Have they ditched VLA?

2.4) without
> do-end .....
>>
>> Read better.
>< C only smells a bit like Algol, I don't even consider it in the Algol family
>unlike {Pascal, ADA, Jovial, Simula } < There is an ADA operating system
>within USA-DOD entirely written in ADA, with handfulls of ASM (similar to
>C<->UNIX)
iWhat's the fuss about ADA, never had a feel a need to learn it, to me
pretty borring syntax. Perhaps because {} is less verbose then BEGIN/END :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-12, BGB <cr88192@gmail.com> wrote:
> On 10/12/2021 4:46 PM, MitchAlsup wrote:
>> On Tuesday, October 12, 2021 at 1:18:42 PM UTC-5, BGB wrote:
>>> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>
>>>>> Victor Yodaiken <victor....@gmail.com> schrieb:
>>>>>
>>>>>> Can you cast a pointer to a different type? Sure.
>>>>>>
>>>>>> Can you dereference it?
>>>>>
>>>>> No.
>>>>
>>>> This statement is wrong, or at best much overstated. There are
>>>> plenty of situations where a C pointer value converted to a
>>>> different type may be safely and portably dereferenced.
>>>> Certainly that isn't always true, but it isn't always false
>>>> either.
>>>>
>>> Yeah. For some types of code it is desirable to be able to cast and
>>> dereference a pointer as whatever type matches what one wants to do with it.
>> <
>> During my career I went to so many meetings about memory referencing
>> and how this/that machine was good/bad, I stabilized my thinking about
>> referencing memory into the camp of::
>> a) memory is Inherently misaligned,
>> b) you can't do anything about making that go away,
>> c) you can make the HW capable of delivering near zero overhead to misalignment;
>> THAT: you should simply design the machine as inherently misaligned.
>> <
>> And at this point, If you create/cast a pointer to something, you CAN
>> dereference it. Whether it is profitable or not is up to the programmer.
>
> Granted.
>
> Nearly all access in BJX2 is misaligned-safe by default, with a few
> partial exceptions which don't significantly effect code generation for
> the most part (mostly effecting the handling of constant displacements
> and MOV.X and similar).
>
>
>>>
>>> Requiring something like, say, using "memcpy()" to mash bits from one
>>> format to another and hoping the compiler is smart and reliable enough
>>> to make this "not suck" is a crap solution, IMHO.
>> <
>> Requiring a trip through memory to get from FP-register to int-register
>> is similarly stupid !! {Note: my restrained hand, here.}
>> <
>> SIMD-register to int-register or FP-register probably remains necessary--
>> because SIMD is not the same (or similar size) as int or FP.
>
> Granted, but these is no way to express this in (standard) C.
> There are compiler intrinsics for this case in BGBCC.
>
> In effect, it is mostly how much extra overhead one wants to impose on
> transferring a value from one register to another.
>
> Meanwhile, the ASM programmer can make use of both integer and FP
> operations using GPRs.
>
>
> This was also a partial incentive for building dynamic typing into
> BGBCC, besides it being needed for my BS2 language: the compiler can do
> all this a lot more efficiently than leaving it up to user code.
>
> In theory, it could also allows for a fairly lightweight JavaScript FFI
> if C code can more directly access JS data and environments without
> needing an awkward and convoluted wrapper API.
>
> Even if, yeah, one probably doesn't want to use dynamic typing when
> avoidable for normal code, in my tests, the performance overhead of
> using dynamic typing is actually surprisingly modest though (as-in,
> "doesn't ruin performance quite as bad as one might intuitively expect
> given it turns pretty much every operator into a runtime call").
>
>
> Full hardware support is unlikely, but it is possible that a few special
> cases can be useful, such as a combined "Morton shuffle and Logical
> Shift Right" operator and similar, or a "Table-Switch with Unsigned
> Saturate".
>
> Say:
> ADD R4, -64, R3
> BRUSS.L 180, R3
> BRA4B .L_case_64
> BRA4B .L_case_65
> ...
> BRA4B .L_case_242
> BRA4B .L_case_243
> BRA4B .L_case_default
>
Isnt it much better just to index into table
and jump?

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-12, John Levine <johnl@taugh.com> wrote:
> According to Branimir Maksimovic <branimir.maksimovic@icloud.com>:
>>>> A vital characteristic of assembly, as a programming language, is that
>>>> the generated code does /exactly/ what you order, no more and no less,
>>>> without re-ordering, optimising, removing or adding anything. C is not
>>>> a language remotely like that, never has been, never will be.
>>><
>>> You have obviously never used a good macro assembler............
>>
>>Macros in assembler are different, you just define macro, that's all :P
>>No surprises...
>
> I'm not getting the impression you've not done a lot of programming in assemblers
> with strong macro languages.
You are absolutelly right. I just speak from my experience :P

Someone else mentioned PDP-10 MACRO, but take a
> look at HLASM (the oddly named High Level Assembler) for IBM mainframes. They
> have macros that with one parameter generate a block of arguments to a call, with
> a different parameter generate the call that uses the arguments, and by default
> generates both.
>
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc264940/$file/asmr1023.pdf
>
iThanks I'll look into. Problem is that nowadays, only HLL are advertised and we assembler
Hackers have to relly on individual efforts, just simple home made assemblers :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-12, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Tuesday, October 12, 2021 at 5:47:41 PM UTC-5, BGB wrote:
>> On 10/12/2021 4:46 PM, MitchAlsup wrote:
>> > On Tuesday, October 12, 2021 at 1:18:42 PM UTC-5, BGB wrote:
>> >> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>> >>> Thomas Koenig <tko...@netcologne.de> writes:
>> >>>
>> >>>> Victor Yodaiken <victor....@gmail.com> schrieb:
>> >>>>
>> >>>>> Can you cast a pointer to a different type? Sure.
>> >>>>>
>> >>>>> Can you dereference it?
>> >>>>
>> >>>> No.
>> >>>
>> >>> This statement is wrong, or at best much overstated. There are
>> >>> plenty of situations where a C pointer value converted to a
>> >>> different type may be safely and portably dereferenced.
>> >>> Certainly that isn't always true, but it isn't always false
>> >>> either.
>> >>>
>> >> Yeah. For some types of code it is desirable to be able to cast and
>> >> dereference a pointer as whatever type matches what one wants to do with it.
>> > <
>> > During my career I went to so many meetings about memory referencing
>> > and how this/that machine was good/bad, I stabilized my thinking about
>> > referencing memory into the camp of::
>> > a) memory is Inherently misaligned,
>> > b) you can't do anything about making that go away,
>> > c) you can make the HW capable of delivering near zero overhead to misalignment;
>> > THAT: you should simply design the machine as inherently misaligned.
>> > <
>> > And at this point, If you create/cast a pointer to something, you CAN
>> > dereference it. Whether it is profitable or not is up to the programmer.
>> Granted.
>>
>> Nearly all access in BJX2 is misaligned-safe by default, with a few
>> partial exceptions which don't significantly effect code generation for
>> the most part (mostly effecting the handling of constant displacements
>> and MOV.X and similar).
>> >>
>> >> Requiring something like, say, using "memcpy()" to mash bits from one
>> >> format to another and hoping the compiler is smart and reliable enough
>> >> to make this "not suck" is a crap solution, IMHO.
>> > <
>> > Requiring a trip through memory to get from FP-register to int-register
>> > is similarly stupid !! {Note: my restrained hand, here.}
>> > <
>> > SIMD-register to int-register or FP-register probably remains necessary--
>> > because SIMD is not the same (or similar size) as int or FP.
>> Granted, but these is no way to express this in (standard) C.
>> There are compiler intrinsics for this case in BGBCC.
>>
>> In effect, it is mostly how much extra overhead one wants to impose on
>> transferring a value from one register to another.
>>
>> Meanwhile, the ASM programmer can make use of both integer and FP
>> operations using GPRs.
>>
>>
>> This was also a partial incentive for building dynamic typing into
>> BGBCC, besides it being needed for my BS2 language: the compiler can do
>> all this a lot more efficiently than leaving it up to user code.
>>
>> In theory, it could also allows for a fairly lightweight JavaScript FFI
>> if C code can more directly access JS data and environments without
>> needing an awkward and convoluted wrapper API.
>>
>> Even if, yeah, one probably doesn't want to use dynamic typing when
>> avoidable for normal code, in my tests, the performance overhead of
>> using dynamic typing is actually surprisingly modest though (as-in,
>> "doesn't ruin performance quite as bad as one might intuitively expect
>> given it turns pretty much every operator into a runtime call").
>>
>>
>> Full hardware support is unlikely, but it is possible that a few special
>> cases can be useful, such as a combined "Morton shuffle and Logical
>> Shift Right" operator and similar, or a "Table-Switch with Unsigned
>> Saturate".
>>
>> Say:
>> ADD R4, -64, R3
>> BRUSS.L 180, R3
>> BRA4B .L_case_64
>> BRA4B .L_case_65
>> ...
>> BRA4B .L_case_242
>> BRA4B .L_case_243
>> BRA4B .L_case_default
><
> ADD R4,R3,#-64
> TJMP R4,#179
> .halfword L_case_64-., L_case_65-.
> .......
> .halfword L_case_242-.,L_case_243-.
> default::
><

Yeah, that's it !
> If all the labels are within 1024 bytes of the TJMP instruction, then the
> table can be comprised of byte offsets (instead of halfword offsets, shown).
><
> No-one can transfer control into the table and get anything other than a
> fault.
>>

Agreed 150% :P

>> Where, any value outside the range of 0..179 goes to 180, while
>> otherwise branching to (PC+Rn*4).
>>
>> Mostly this is because dynamically-typed runtime-support code internally
>> tends to make fairly heavy use of "switch()".
>>
>> At present, this would be done more like:
>> ADD R4, -64, R3
>> CMPHI 179, R3
>> BT .L_case_default
>> BRA.L R3
>> BRA4B .L_case_64
>> BRA4B .L_case_65
>> ...
>> BRA4B .L_case_242
>> BRA4B .L_case_243
>>
> Similar TJMP sequence as above.

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 10/12/2021 5:54 PM, Branimir Maksimovic wrote:
> On 2021-10-12, MitchAlsup <MitchAlsup@aol.com> wrote:
>> On Tuesday, October 12, 2021 at 4:19:34 PM UTC-5, victor....@gmail.com wrote:
>>> On Tuesday, October 12, 2021 at 8:39:58 AM UTC-5, David Brown wrote:
>>>
>>>> But do I take it that you agree with me that C is not a "high-level
>>>> assembly"?
>>> The first paragraph of the paper ---- The C programming language [33] is the
>>> first, and, so far,only widely successful programming language that provides
>>> operating system developers with a high-level language alternative to
>>> assembler (compare to [42]). C’s success was predicated on its design: a
>>> small language, close to the machine yet with a great deal of flexibility
>>> for experienced programmers. The Rationale for the C standard [9] cited C’s
>>> capability to function as a "high-level assembler" and explained that"many
>>> operations are defined to be how the target machine’s hardware does it
>>> rather than by a general abstract rule" but C also has traditional
>>> attributes of an ALGOL style programming language. -----
>>>
>>> Note, among other phrases: 1) a high-level language alternative to assembler
>>> 2) C also has traditional attributes of an ALGOL style programming language.
>> 2.1) without nesting of {blocks, subroutines, data} 2.2) without strict
>> typing 2.3) without allocating dynamic arrays on the stack
>
> Have they ditched VLA?
>
> 2.4) without
>> do-end .....
>>>
>>> Read better.
>> < C only smells a bit like Algol, I don't even consider it in the Algol family
>> unlike {Pascal, ADA, Jovial, Simula } < There is an ADA operating system
>> within USA-DOD entirely written in ADA, with handfulls of ASM (similar to
>> C<->UNIX)
> iWhat's the fuss about ADA, never had a feel a need to learn it, to me
> pretty borring syntax. Perhaps because {} is less verbose then BEGIN/END :P
>

To me, the big advantage of Ada (it's a woman's name, not an acronym -
hence not all caps) is that its syntax makes it easier to write correct
programs, and harder, though of course not impossible, to make the kind
of errors this thread has been talking about.

But others here are far more qualified to discuss this than I am.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> To me, the big advantage of Ada (it's a woman's name, not an acronym -
> hence not all caps) is that its syntax makes it easier to write correct
> programs, and harder, though of course not impossible, to make the kind
> of errors this thread has been talking about.
>
> But others here are far more qualified to discuss this than I am.
>
OK, I'll try it, it, but on macOS I can't have compiler, let alone
IDE support :P
>
>
>

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>> hence not all caps) is that its syntax makes it easier to write correct
>> programs, and harder, though of course not impossible, to make the kind
>> of errors this thread has been talking about.
>>
>> But others here are far more qualified to discuss this than I am.
>>
> OK, I'll try it, it, but on macOS I can't have compiler, let alone
> IDE support :P

Again, others are more qualified than I am to comment, but it appears
that GNAT (GNU Ada compiler) is available on MacOS.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 2021-10-13 3:54, Branimir Maksimovic wrote:

> What's the fuss about ADA, never had a feel a need to learn it,

Since you ask, here are a some reasons to be interested in Ada:

- "Conclusion: development costs of C exceed those of Ada":
http://archive.adaic.com/intro/ada-vs-c/cada_art.html

- "Why Ada succeeds where C fails":
http://archive.adaic.com/projects/atwork/trains.html

- "Our research showed that Ada’s evolution has made it an increasingly
compelling option for engineering organizations":
https://www.adacore.com/uploads/techPapers/Controlling-Costs-with-Software-Language-Choice-AdaCore-VDC-WP.PDF

> to me pretty borring syntax. Perhaps because {} is less verbose then
> BEGIN/END :P

Maybe boring, but designed for readability and robustness at the
possible cost of brevity.

On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>> hence not all caps) is that its syntax makes it easier to write correct
>>> programs, and harder, though of course not impossible, to make the kind
>>> of errors this thread has been talking about.
>>>
>>> But others here are far more qualified to discuss this than I am.
>>>
>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>> IDE support :P
>
> Again, others are more qualified than I am to comment, but it appears
> that GNAT (GNU Ada compiler) is available on MacOS.
>

Yes, but is only for x86, does not builds for my M1.
Interrestingly except gforth (without extensions)
there is no forth for M1, as well.
>
>

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-13, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 2021-10-13 3:54, Branimir Maksimovic wrote:
>
>> What's the fuss about ADA, never had a feel a need to learn it,
>
>
> Since you ask, here are a some reasons to be interested in Ada:
>
> - "Conclusion: development costs of C exceed those of Ada":
> http://archive.adaic.com/intro/ada-vs-c/cada_art.html
>
> - "Why Ada succeeds where C fails":
> http://archive.adaic.com/projects/atwork/trains.html
>
> - "Our research showed that Ada’s evolution has made it an increasingly
> compelling option for engineering organizations":
> https://www.adacore.com/uploads/techPapers/Controlling-Costs-with-Software-Language-Choice-AdaCore-VDC-WP.PDF
>
>
>> to me pretty borring syntax. Perhaps because {} is less verbose then
>> BEGIN/END :P
>
> Maybe boring, but designed for readability and robustness at the
> possible cost of brevity.
Great, but there must be more effort in ads for ADA, as C
is everywhere available, while behind ADA is lack of support :(

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 12/10/2021 20:18, BGB wrote:
> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>>
>>>> Can you cast a pointer to a different type?  Sure.
>>>>
>>>> Can you dereference it?
>>>
>>> No.
>>
>> This statement is wrong, or at best much overstated.  There are
>> plenty of situations where a C pointer value converted to a
>> different type may be safely and portably dereferenced.
>> Certainly that isn't always true, but it isn't always false
>> either.
>>
>
> Yeah. For some types of code it is desirable to be able to cast and
> dereference a pointer as whatever type matches what one wants to do with
> it.
>

He didn't say it was "desirable", he said it is possible (in a fully
defined, safe and portable way).

If you start out with "int * p", then you can do:

const int * p1 = (const int *) p;
int x = *p1;

char * p1 = (char *) p;
int x = *p1; // You get the first byte

short * p1 = (short *) p;
int * p2 = (int *) p1;
int x = *p2;

These are just a few examples where casting a pointer to a different
type, then dereferencing it, is fine. There are many others (such as
using structs, unions, arrays, uintptr_t, etc.).

But equally there are many casts where the cast itself is fully defined
(or almost fully, depending on alignments), but dereferencing would not
be defined behaviour.

It is not the casting that is the problem - it is the accessing of the
object via an lvalue of an incompatible type that is not covered by one
of the other clauses in 6.5p7.

On 12/10/2021 23:46, MitchAlsup wrote:
> On Tuesday, October 12, 2021 at 1:18:42 PM UTC-5, BGB wrote:
>> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>>>
>> Yeah. For some types of code it is desirable to be able to cast and
>> dereference a pointer as whatever type matches what one wants to do with it.
> <
> During my career I went to so many meetings about memory referencing
> and how this/that machine was good/bad, I stabilized my thinking about
> referencing memory into the camp of::
> a) memory is Inherently misaligned,
> b) you can't do anything about making that go away,
> c) you can make the HW capable of delivering near zero overhead to misalignment;
> THAT: you should simply design the machine as inherently misaligned.
> <
> And at this point, If you create/cast a pointer to something, you CAN
> dereference it. Whether it is profitable or not is up to the programmer.

That is a perfectly reasonable viewpoint. It is not, however, the
viewpoint taken by the C language standards - no matter how you might
object. Disagreeing with them does not change reality.

>>
>> Requiring something like, say, using "memcpy()" to mash bits from one
>> format to another and hoping the compiler is smart and reliable enough
>> to make this "not suck" is a crap solution, IMHO.
> <
> Requiring a trip through memory to get from FP-register to int-register
> is similarly stupid !! {Note: my restrained hand, here.}
> <
That is why good compilers do not make the trip through memory.

float int_to_float(int x) {
float f;
memcpy(&f, &x, sizeof(x));
return f;
}

int_to_float:
movd xmm0, edi
ret

Requiring a /logical/ trip through memory is inconvenient too. That is
why C also allows type-punning unions:

float int_to_float2(int x) {
union { int i; float f; } u = { x };
return u.f;
}

int_to_float2:
movd xmm0, edi
ret

Sometimes, however, it would be nice if you could use pointer syntax
directly and access other data types in a simpler manner. That is why
gcc has an extension to specify precisely that:

float int_to_float3(int x) {
typedef __attribute__ ((__may_alias__)) float float_a;
int y = x;
float_a * fp = (float_a *) &y;
return *fp;
}

However, I agree with BGB that it is a shame there is no good, simple,
method that is safe and also efficient on all compilers. Generally,
poorer quality compilers will generate inefficient code when dealing
with memcpy and perhaps also unions - but such compilers don't do TBAA
and so dereferencing converted pointers typically "works". (However,
they rarely /document/ and /guarantee/ that it will work.)

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:

> And the problem is that as soon as you use `<` on pointers to different
> objects you run the risk of firing rockets, even though `<` is supposed
> to be a pure function returning a boolean.
>
> I'm fine with a C standard that says that which boolean is returned is
> undefined (and I'm even willing to let it be not-quite-pure and not
> always return the same value when called with the same two pointers),

I believe "nasal demons" is the more traditional way to call this :-)
> but firing rockets is a bit excessive here, don't you think?
> There should also be a "quality of implementation" note stating that on
> systems where it makes sense, `<` should be pure and obey the expect
> rules like anti-symmetry etc...

QOI belongs to the compiler, not to the standard.

There is also the restriction on the complexity, which makes

#! /bin/sh
echo "Program to complex, aborting" 1>&2

a valid C compiler according to the standard.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

> AFAIAA none of flags used in compiling programs like the Linux
> kernel render the implementation non-conforming, and if the
> implementation is conforming then by definition the language
> being compiled is C.

One of the weaker points of the C standard.

I can with some justification claim that gfortran is a conforming
C implementation. Let's test:

$ cat hello.c
#include <stdio.h>

int main()
{ printf ("Hello, world!\n");
return 0;
} $ gfortran hello.c
$ ./a.out
Hello, world!

Yet, gfortran also compiles this:

$ cat hello.f
PROGRAMME MAIN
WRITE (*,1000)
1000 FORMAT (11HHELLO WORLD)
END
$ gfortran hello.f
$ ./a.out
HELLO WORLD
$

So, is the program hello.f C?

Branimir Maksimovic <branimir.maksimovic@icloud.com> schrieb:
> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>> programs, and harder, though of course not impossible, to make the kind
>>>> of errors this thread has been talking about.
>>>>
>>>> But others here are far more qualified to discuss this than I am.
>>>>
>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>> IDE support :P
>>
>> Again, others are more qualified than I am to comment, but it appears
>> that GNAT (GNU Ada compiler) is available on MacOS.
>>
>
> Yes, but is only for x86, does not builds for my M1.
> Interrestingly except gforth (without extensions)
> there is no forth for M1, as well.

AFAIK, there will be M1 support in gcc 12. Interestingly enough,
it was the lack of a Fortran compiler which mostly drove demand
for this port.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>
>>> Can you cast a pointer to a different type? Sure.
>>>
>>> Can you dereference it?
>>
>> No.
>
> This statement is wrong, or at best much overstated.

You are right there.

However, modern compiler technology offers an alternative:
memcpy is now very well optimized, and what appears to
be moving data around is in fact optimized away.

AFAIK, this is then implementation-defined behavior, not
undefined behavior.

On 12/10/2021 16:02, Stefan Monnier wrote:
>> Eh, no. If that was the point of the article, it's wrong. Plain and
>> simple. This is easily demonstrated by the fact that pretty much all
>> modern operating systems /are/ written almost entirely in C.
>
> Well, maybe a language closely related to C, but not really C.
> That's why they need special flags passed to the compiler before the
> result is usable.
>
>> You can compare them for equality (if they are of compatible types, or
>> one is a null pointer), not for relation, unless they are part of the
>> same object. This makes sense, because C does not require a single
>> linear address space - and there are real targets (with real OS's,
>> written in C) that have independent address spaces.
>
> And the problem is that as soon as you use `<` on pointers to different
> objects you run the risk of firing rockets, even though `<` is supposed
> to be a pure function returning a boolean.

"<" is a pure function, but not a /complete/ function in C. That is,
there are inputs for which it guarantees a defined output (defined by
the C standards and/or an implementation), and for anything else, it is
garbage in, garbage out. Sometimes the garbage out is the explosive kind.

This concept has been understood since the beginning of programmable
computers:

"""
On two occasions I have been asked [by members of Parliament], 'Pray,
Mr. Babbage, if you put into the machine wrong figures, will the right
answers come out?' I am not able rightly to apprehend the kind of
confusion of ideas that could provoke such a question.
"""

>
> I'm fine with a C standard that says that which boolean is returned is
> undefined (and I'm even willing to let it be not-quite-pure and not
> always return the same value when called with the same two pointers),
> but firing rockets is a bit excessive here, don't you think?

I'm not really very keen on this "give me an answer, I don't care if it
is right" idea. I am much happier, when possible, to get "I refuse to
compile this program because you've made a mistake".

Compilers don't usually fire rockets - contrary to what some people seem
to imagine, they don't go out of their way to cause trouble when someone
makes a mistake in their code. They aim to make the most efficient code
on the assumption that you give valid inputs to the various functions,
operators, etc., of the language, and that you don't care what happens
if the inputs are invalid. Very often that gives you the "naïve"
results even on invalid inputs, but sometimes it can give unexpected
effects.

> There should also be a "quality of implementation" note stating that on
> systems where it makes sense, `<` should be pure and obey the expect
> rules like anti-symmetry etc...
>

Why? When is it useful? About the only case I can think of is when
implementing memmove(), and that is part of the system library and can
use any implementation-specific trick or extension it wants.

On 12/10/2021 18:42, Stefan Monnier wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (Btw, if you choose to respond to this posting and quote some of
>> what I have said but do not give an attributing citation, then
>> you're an asshole.)
>
> Not sure what I was thinking when I wrote that, sorry,
>

I would not have put it quite like Tim, but I suspect a lot of people
here (including me) would prefer that you followed standard Usenet
posting, quoting and attributing conventions. The conventions were
developed for good reasons.

On 12/10/2021 16:48, MitchAlsup wrote:
> On Tuesday, October 12, 2021 at 8:39:58 AM UTC-5, David Brown wrote:
>> On 11/10/2021 20:04, Victor Yodaiken wrote:
>>> On Sunday, October 10, 2021 at 5:48:01 AM UTC-5, David Brown wrote:
>>>
>>>> The idea of C being a "high-level assembler" is right there in
>>>> section 1, "Introduction".
>>>>
>>>
>>> There is something about high level assembler in the introduction -
>>> it is a QUOTE from the C Rationale. If you honestly interpreted it as
>>> a claim that C was supposed to be a complete replacement for all
>>> assembly languages, then maybe you need new glasses.
>>>
>> I know that what you wrote was a quotation from a C Rationale document.
>> Clearly I did not interpret it as you suggest - you cannot complain
>> that I have exaggerated your writings and then do /exactly/ the same
>> thing yourself! The difference, however, is that I was doing so as a
>> criticism of your argument - you appear to be doing so as some kind of
>> revenge.
>>
>>
>> But do I take it that you agree with me that C is not a "high-level
>> assembly"?
>>
>> A vital characteristic of assembly, as a programming language, is that
>> the generated code does /exactly/ what you order, no more and no less,
>> without re-ordering, optimising, removing or adding anything. C is not
>> a language remotely like that, never has been, never will be.
> <
> You have obviously never used a good macro assembler............

Macro assemblers do not re-order, optimise, add or remove code. When
you "call" a macro, you get exactly the code the macro specifies, just
as if you had written it by hand. The same applies if you use loops,
abbreviations, etc.

I don't write much assembly these days - a few lines of inline assembly
is usually sufficient for my needs. But I used to do a lot of assembly
programming, mostly on small microcontrollers, and made a lot of use of
macros.

However, there /are/ some assemblers that will do a little optimisation
and re-arrangement, so I was somewhat imprecise. It's not uncommon for
processors to have relative branch instructions of different lengths,
and some toolchains will optimise these - you use a generic form in the
assembly, and when linking the smallest form is used. Some are even
smarter in handling conditional branches over longer distances. And for
some targets, such as MIPS, assemblers can do delay slot re-ordering
optimisations.

>> There should also be a "quality of implementation" note stating that on
>> systems where it makes sense, `<` should be pure and obey the expect
>> rules like anti-symmetry etc...
> Why? When is it useful?

It's quite handy to store objects in a binary tree.

Stefan

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> AFAIAA none of flags used in compiling programs like the Linux
[..]

>
> So, is the program hello.f C?

https://www.ioccc.org/1986/applin/hint.html

On 13/10/2021 00:50, John Levine wrote:
> According to Branimir Maksimovic <branimir.maksimovic@icloud.com>:
>>>> A vital characteristic of assembly, as a programming language, is that
>>>> the generated code does /exactly/ what you order, no more and no less,
>>>> without re-ordering, optimising, removing or adding anything. C is not
>>>> a language remotely like that, never has been, never will be.
>>> <
>>> You have obviously never used a good macro assembler............
>>
>> Macros in assembler are different, you just define macro, that's all :P
>> No surprises...
>
> I'm not getting the impression you've not done a lot of programming in assemblers
> with strong macro languages. Someone else mentioned PDP-10 MACRO, but take a
> look at HLASM (the oddly named High Level Assembler) for IBM mainframes. They
> have macros that with one parameter generate a block of arguments to a call, with
> a different parameter generate the call that uses the arguments, and by default
> generates both.
>
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc264940/$file/asmr1023.pdf
>

This kind of thing is stretching the definition of what /I/ would call a
"macro". I think "High Level Assembler" is probably more accurate.

However, while this kind of thing makes it /hard/ to determine exactly
what machine code you get in the end, it is still fully determined by
the source code alone (including the definitions of the macros as part
of the source). You don't choose different optimisation levels, and you
don't have different results generated by different tools or different
versions. Is that not correct?

On 13/10/2021 11:11, Branimir Maksimovic wrote:
> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>> programs, and harder, though of course not impossible, to make the kind
>>>> of errors this thread has been talking about.
>>>>
>>>> But others here are far more qualified to discuss this than I am.
>>>>
>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>> IDE support :P
>>
>> Again, others are more qualified than I am to comment, but it appears
>> that GNAT (GNU Ada compiler) is available on MacOS.
>>
>
> Yes, but is only for x86, does not builds for my M1.
> Interrestingly except gforth (without extensions)
> there is no forth for M1, as well.

I think that is mainly due to Apple's determination to stop people using
Apple devices for any development other than Apple applications using
Apple's tools and paying Apple's fees (for whatever they can get away
with). I can appreciate that an M1 machine gives you a lot of
processing power in a small and low-power device, but they seem to be
competing with Windows in their battle to make programmers' and small
developers' lives as inconvenient as possible.

Maybe they'll make an Ada front-end to clang, and call it "gnat" to
confuse their users like they did with their C compiler.