Wednesday, November 16, 2022

Digest for comp.lang.c++@googlegroups.com - 16 updates in 8 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 16 05:41AM -0800


> True, but for really supporting such exotic platforms one would need
> to run tests on these platforms (or at least in an emulator) during
> the development and potentially also later if anything changes.
 
Perhaps some tests, but not necessarily all tests. Any parts of
the program that are verifiably platform agnostic would not need
platform-specific re-testing. Also, any platform-specific tests
don't have to be run during development, but only just before the
program is deployed on the exotic platforms in question, which
could be significantly later than the original development.
 
> Software without tests is just a work of literature.
 
A hyperbolic statement if ever there was one.
Michael S <already5chosen@yahoo.com>: Nov 16 06:24AM -0800

On Thursday, October 13, 2022 at 3:16:54 A
> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've
> heard that it's common for CHAR_BIT to be 16 or 32 in implementations
> for DSPs.
 
Late reaction, sorry.
No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller
with DSP linage. C28 architecture is a 32-bit extension of C24
architecture which, in turn, is a derivative of TMS320C10 architecture
of early 1980s that was a [world's first popular] DSP.
TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10
(via C25 and C54). This one is a DSP.
 
Why one is DSP and another is microcontroller?
Mostly because TI decided to call them taht way.
It is possible to find technical justifications as well, in their respective
architectures, micro-architectures and especially in sets of peripheral,
but all that is secondary to the will of manufacturer.
 
 
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 16 10:38AM -0800

> don't have to be run during development, but only just before the
> program is deployed on the exotic platforms in question, which
> could be significantly later than the original development.
 
How do you know that a part of program is "verifiably platform agnostic"
without platform-specific testing? How else would that be verified?
 
>> Software without tests is just a work of literature.
 
> A hyperbolic statement if ever there was one.
 
Sure, but only slightly hyperbolic.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
olcott <polcott2@gmail.com>: Nov 16 09:31AM -0600

Do you agree with professor Sipser or the many dozens of people that
reject the notion of a simulating halt decider?
 
Disagreement requires that an error with (a) or (b) or (c) exists
or that (d) is not a necessary consequence of (a)(b)(c)
 
The only rebuttal of my work in thousands of reviews for the last two
years is the rejection of this notion of a simulating halt decider.
 
*H correctly simulates its input D until H correctly determines*
*that its simulated D would never stop running unless aborted*
 
(a) A halt decider must report on the actual behavior specified by its
input.
 
(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.
 
(c) A correctly simulated input that would never stop running unless
aborted does specify non-halting behavior.
 
(d) Therefore a simulating halt decider does correctly determine the
halt status of its input.
 
void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
 
int main()
{
Output("Input_Halts = ", H(D, D));
}
 
Once this notion is accepted then the fact that H correctly determines
the halt status of D is verified entirely on the basis of software
engineering.
 
MIT Professor Michael Sipser specifically approved this verbatim
definition as the abstract to this paper. (He neither reviewed nor
approved anything else).
 
If simulating halt decider *H correctly simulates its input D*
*until H correctly determines that its simulated D would never*
*stop running unless aborted* then H can abort its simulation
of D and correctly report that D specifies a non-halting
sequence of configurations.
 
*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
 
 
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 15 04:19PM -0800

>> the standard; it has nothing to do with whether something
>> "defines" the behavior.
 
> The effect of undefined behavior [...]
 
Undefined behavior is a classification; it doesn't have effects.
Moreover the classification holds regardless of how an
implementation might treat constructs that are so classified.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 15 05:10PM -0800

> objects of different types at different times; it says nothing
> about type punning. (The version of C discussed in the 1975 manual
> didn't have unions.)
 
Even so, clearly it was expected that unions would be used for
type punning, and that type punning would work the same way it
works now, even during the early days of C between K&R1 and when
the original ANSI C committee was formed. Evidence for this
assertion may be found in the C Rationale document, which says
nothing about using unions for type punning. The lack of any
mention in the Rationale document means it must have been common
practice in the early days, otherwise it would have been new
behavior and surely would have been discussed and debated and
written up in the Rationale document. Because it wasn't, unions
obviously were being used that way all along.
"Öö Tiib" <ootiib@hot.ee>: Nov 15 11:02PM -0800

On Wednesday, 16 November 2022 at 02:19:46 UTC+2, Tim Rentsch wrote:
> >> "defines" the behavior.
 
> > The effect of undefined behavior [...]
 
> Undefined behavior is a classification; it doesn't have effects.
 
You managed to read 5 words?
I meant effect to people/organizations who implement a
compiler as specified by standard.
Juha Nieminen <nospam@thanks.invalid>: Nov 16 09:26AM

> Even so, clearly it was expected that unions would be used for
> type punning,
 
I'm not sure it's that evident.
 
'union' in C sounds a lot more like a space optimization. A way to
reuse the same memory location to store different types. Like a tuple
which can only hold one value at a time (and the main impetus in this
existing is to save valuable memory, if you indeed only need one type
of value for that object at a time).
 
I don't see how it's so obvious that 'union' was designed from the
get-go with the intent of using it for type punning. Could just as
well be an unintended or semi-intended "side effect" (which may be
platform-specific, ie. not guaranteed to work if the target platform
doesn't support such a thing).
David Brown <david.brown@hesbynett.no>: Nov 16 02:36PM +0100

On 16/11/2022 10:26, Juha Nieminen wrote:
> well be an unintended or semi-intended "side effect" (which may be
> platform-specific, ie. not guaranteed to work if the target platform
> doesn't support such a thing).
 
It's worth noting that in C++, unions specifically cannot be used for
type-punning. If type-punning were considered a major use of unions at
the time C++ was being standardised, I think it is reasonable to suppose
C++ would have allowed it (perhaps with restrictions to POD types)
rather than clearly disallowing it. I realise that reasoning is weak -
but no weaker than Tim's reasoning that C supported type-punning from an
early stage.
 
In general, I do not think it is right to think "the standard doesn't
ban it, so it is allowed", or "the rationale doesn't mention it, so it
must have been viewed as obvious". The C standard makes it clear that
behaviour that is not described is as much "undefined behaviour" as
things that are explicitly marked as "undefined behaviour". So in C90,
AFAICS, using a union for type punning is just like dereferencing a null
pointer, or calling a function with the wrong number or type of
parameters, or any other undefined behaviour.
 
That is why we have a language /standard/ - not just some interesting
rationale documents.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 15 05:26PM -0600

On 11/14/2022 7:36 PM, Keith Thompson wrote:
 
>> I used the gettimeofday function. Works well !
 
> Be aware that POSIX says gettimeofday() is obsolescent, and recommends
> clock_gettime() instead.
 
This works fine for me:
 
// from:
//
https://stackoverflow.com/questions/10905892/equivalent-of-gettimeday-for-windows
 
struct timezone {
int tz_minuteswest;
int tz_dsttime;
};
 
int mygettimeofday (struct timeval *tv, struct timezone *tz)
{
if (tv) {
FILETIME filetime; /* 64-bit value representing the
number of 100-nanosecond intervals since January 1, 1601 00:00 UTC */
ULARGE_INTEGER x;
ULONGLONG usec;
static const ULONGLONG epoch_offset_us = 11644473600000000ULL; /*
microseconds betweeen Jan 1,1601 and Jan 1,1970 */
 
#if _WIN32_WINNT >= _WIN32_WINNT_WIN8
GetSystemTimePreciseAsFileTime ( & filetime);
#else
GetSystemTimeAsFileTime ( & filetime);
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)