| olcott <NoOne@NoWhere.com>: Feb 26 01:53PM -0600 (1) We know that every software function invoked with the same data must have the same execution trace. (2) When a software function invokes itself this is recursive invocation. (3) When the second recursive invocation of a software function calls itself with the same data as the prior invocation then it must have the same execution trace as the prior invocation. (4) When the second recursive invocation of a software function calls itself with the same data has no conditional branch instructions inbetween these two invocations then this is a case of infinite recursion. (5) When the recursive invocation is replaced with a call to a software system that simulates the execution of the calling function with its same data, then this is equivalent to a recursive invocation. // P has address of H_Hat void H_Hat(u32 P) { Simulate(P, P); } Does everyone agree? -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Siri Cruise <chine.bleu@yahoo.com>: Feb 26 12:48PM -0800 In article <3LadneKdoK8jzKT9nZ2dnUU78T3NnZ2d@giganews.com>, > Does everyone agree? P = \a.P(succ(a)) P 0 > (1) We know that every software function invoked with the same data must > have the same execution trace. When does a recursion use the same data? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \ I am an Andrea Doria sockpuppet. insults Islam. Mohammed |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 26 09:37PM On 26/02/2021 19:53, olcott wrote: > Simulate(P, P); > } > Does everyone agree? No. (-1) In general for an algorithm or program to perform useful work its functions contain branching logic. (0) Only pure functions may not modify mutable state. ... (6) ??? (7) ??? (8) ??? ... (???) ??? ... /Flibble -- 😎 |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 03:17PM +0100 Lambdas with no captures can be handled like ordinary functions and you can get the address of the lambda as a normal function-pointer. AFAIK there's no compiler which allows to specify a callig-convention on a lambda. But with MSVC you can convert a lamda to a function-pointer of any type, i.e. you can convert it to __cdecl, __fastcall or whatever (they exist for x86 only, x64 has a consistent calling convention for all calls). What MSVC does here is that it compiles the lambda multiple times for each calling convention on demand. Look here: #include <iostream> #include <string> #include <iomanip> #include <cstdint> using namespace std; void fastCall( void (__fastcall *pf)( string ) ) { string str = "hello world"; cout << p << endl; pf( str ); } void cdeclCall( void (__cdecl *pf)( string ) ) { string str = "hello world"; cout << p << endl; pf( str ); } int main() { auto lambda = []( string str ) { cout << str << endl; }; fastCall( lambda ); cdeclCall( lambda ); } As you can see the addresses pf vary. You might think that the compiler generates proxy-code and the string is copy-constructed with each proxy. But I disassembled the lambda and found that the lambda is compiled completely multiple times. So are there any other compilers which have different calling conven- tions and which do the same ? |
| David Brown <david.brown@hesbynett.no>: Feb 26 05:08PM +0100 On 26/02/2021 15:17, Bonita Montero wrote: > (they exist for x86 only, x64 has a consistent calling convention for > all calls). What MSVC does here is that it compiles the lambda multiple > times for each calling convention on demand. Calling conventions - especially the various ones supported by MSVC - are very much implementation specific. On most platforms you have a single ABI that all compilers adhere to, but not on 32-bit Windows. So how different calling conventions are handled on Win32 will be entirely up to the compiler. Lambdas have internal linkage and are usually not "exported" in any way, so compilers are free to use whatever calling conventions they want - there is no need for any consistency, especially if the lambda is a leaf function. When you convert a lambda to a pointer-to-function, you are actually using a conversion function template which is free to give different results for different pointer types. (It can even give different results for the same pointer types, although that would be less likely in a real implementation.) See the section on "ClosureType::operator ret(*)(params)()" : <https://en.cppreference.com/w/cpp/language/lambda> Of curiosity, what happens if you replace the lambda with a static function: static auto lambda(string str) { cout << str << endl; } ? |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:21PM +0100 > Calling conventions - especially the various ones supported by MSVC - > are very much implementation specific. On most platforms you have a > single ABI that all compilers adhere to, ... On Windows x64 there's no such thing as __cdecl, __fastcall, __stdcall etc. anymore. |
| David Brown <david.brown@hesbynett.no>: Feb 26 05:41PM +0100 On 26/02/2021 17:21, Bonita Montero wrote: >> single ABI that all compilers adhere to, ... > On Windows x64 there's no such thing as __cdecl, __fastcall, __stdcall > etc. anymore. Well, MS didn't do nearly as badly for Win64 as they did for Win32 (where there are half a dozen conventions) or DOS (where there is so little defined that it's a stretch to use the word "convention"). They tried to have a single ABI - though in good old MS fashion, they saw that everyone else had settled on a single consistent ABI and thus decided they needed a completely different one instead. But there is still the "normal" MS Win64 calling convention, and the "__vectorcall" version. However, I thought you were specifically talking about Win32 since you were talking about __cdecl, __fastcall, etc., ? |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:43PM +0100 > decided they needed a completely different one instead. But there is > still the "normal" MS Win64 calling convention, and the "__vectorcall" > version. With most other platforms there's usually a default calling convention and mostly a cdecl calling convention which pushes everything on the stack. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:48PM +0100 Am 26.02.2021 um 15:17 schrieb Bonita Montero: > { > string str = "hello world"; > cout << p << endl; pf, not p > { > string str = "hello world"; > cout << p << endl; pf, not p |
| scott@slp53.sl.home (Scott Lurndal): Feb 26 05:26PM >With most other platforms there's usually a default calling convention >and mostly a cdecl calling convention which pushes everything on the >stack. Most platforms I've seen in the past two decades use calling conventions that pass the first N parameters in registers, where N varies based on the number of registers. E.g. x86_64 on unix/linux (N=6), Motorola 88100, IA64, et alia. Calling conventions also agree on how to handle varargs and how to pass SIMD, vector (and for ARM, scalable vector) values. |
[ANNOUNCE] Documentation preview for latest NHI1, libmsgque and the Programming-Language-Microkernel
| aotto1968 <aotto1968@t-online.de>: Feb 26 02:05PM +0100 Hello everybody, After a while, I would like you to be informed about my current (C++) project: NHI1 - the POWER of programming → https://nhi1.selfhost.co/wiki/index.php?title=NHI1_-_the_POWER_of_programming ========================================================================== It is difficult to describe the POWER of NHI1 in a few simple words - let me try: NHI1 - something that writes code for you The Something is a collection of tools, libraries, and design patterns that push the boundaries of programming. ========================================================================== Some example-tools and libraries are also available: NHI1 - HOME page → https://nhi1.selfhost.co/nhi1 ccmsgque - an C++ application-server library → https://nhi1.selfhost.co/nhi1/ccmsgque/ccmsgqueref.htm mpgrep a massive parallel grep tool → https://nhi1.selfhost.co/nhi1/ccmsgque/cc_MpGrep.htm Compiler Factory - Company HOME page → https://nhi1.selfhost.co mfg |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment