- Seems like the double * and double ** are put on stack in reverse order expected - 1 Update
- fwiw, some field line based DLA... - 1 Update
- mixing compilers (g++ but Intel others)? - 13 Updates
- std::accumulate and lamda - 3 Updates
- "GNU compilers learn new C++, parallelism tricks" - 1 Update
- Difference between array and pointer - arguments - 1 Update
red floyd <no.spam.here@its.invalid>: Apr 19 10:38PM -0700 On 4/19/2016 7:09 AM, Scott Lurndal wrote: > and useful addressing modes. >> they were on the inside. Possibly put off by PIP and STAT commands. :( > Should have used UnixV6 instead of RSX-11M/RSTS-E. The TI 34010 Graphics processor communicated with the host CPU via memory mapped registers. You'd load the address register with the address in 34010 memory space, and then write to the data register. Successive writes would increment the address register, so that you could load graphics data by successive writes to the data register. |
"Chris M. Thomasson" <nospam@nospam.no>: Apr 29 03:45PM -0700 FWIW, some, IMHO, fairly interesting C++ code for Field Based DLA: https://plus.google.com/101799841244447089430/posts/am5EpMHcmig https://github.com/ChrisMThomasson/CT_fieldDLA https://en.wikipedia.org/wiki/Diffusion-limited_aggregation that can be heavily multithreaded! the code as is, creates the following rendering: https://plus.google.com/101799841244447089430/posts/DfjAJbbdLGp Four C++ files, that use the Cairo graphics lib along with the GLM library: http://cairographics.org/ http://glm.g-truc.net/0.9.7/index.html No need to follow random walks, follow field lines for DLA? C++ seems like a _very_ nice place to implement this. :^) |
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:40AM -0400 On 4/29/2016 1:20 AM, Öö Tiib wrote: > defines object or library file formats or application binary interfaces > so they can. You however very verbosely keep failing to give examples of > users of that freedom in Unix land. And you can keep demanding all you want. One of these days, I might be talking to one of my past clients and get the details. I don't remember what every client I ever worked with runs. But it's not important enough to me to bug them with trivial questions. However, everyone else here seems to claim that ar is required to build .a files, and all .o files are the same format. It shows just how limited your experience is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:42AM -0400 On 4/29/2016 4:14 AM, Ian Collins wrote: >> it wasn't gcc. However, it's not important enough for me to give a damn. > So as usual you can't back up your nonsensical claims. Why do you > bother posting bollocks? I guess you don't give a damn. Nope, it's just not important enough for me to try to teach a pig to sing. Your comments prove the extent of your ignorance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:43AM -0400 On 4/29/2016 8:46 AM, Scott Lurndal wrote: >> the educational world. Not even AT&T was using it very much for production. > Interesting, indeed, as I was working for a University on > a PDP-11/34 writing unix drivers for test hardware. Let's see. You were working for a University. I said they were used in the educational world. I guess to you a University is not part of the educational world. I guess you never learned comprehension at your "university". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
"Öö Tiib" <ootiib@hot.ee>: Apr 29 08:44AM -0700 On Friday, 29 April 2016 17:41:06 UTC+3, Jerry Stuckle wrote: > talking to one of my past clients and get the details. I don't remember > what every client I ever worked with runs. > But it's not important enough to me to bug them with trivial questions. I do not demand. I say that it leaves your assertions bald and empty denial of reality. > However, everyone else here seems to claim that ar is required to build > .a files, and all .o files are the same format. It shows just how > limited your experience is. You are moving goalposts here. Others claim that with advent of portable operating systems some object file formats have been defined and used on different kinds of systems. The formats are not used because someone requires that. Formats are used because everybody wants to achieve compatibility with others. Who does not falls out of pack and loses. No one is required to make say .zip files using a PKZIP program and if they use something else they are still not required to produce ZIP format specified by ISO/IEC 21320-1:2015. Everybody just wants to. |
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 12:23PM -0400 On 4/29/2016 11:44 AM, Öö Tiib wrote: >> But it's not important enough to me to bug them with trivial questions. > I do not demand. I say that it leaves your assertions bald and empty > denial of reality. And what you think is of absolutely no importance to me. > on different kinds of systems. The formats are not used because someone > requires that. Formats are used because everybody wants to achieve > compatibility with others. Who does not falls out of pack and loses. No, I have moved no goalposts. My statements have been consistent since the start. Just because your limited experience hasn't exposed you to other options does not mean they don't exist. > No one is required to make say .zip files using a PKZIP program and if > they use something else they are still not required to produce ZIP > format specified by ISO/IEC 21320-1:2015. Everybody just wants to. Now who's moving the goalposts - or at least bringing up another red herring? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 02:28PM -0400 On 4/28/2016 5:01 PM, David Brown wrote: > made it perfectly clear that I don't believe it can be done, and > certainly don't know of any method. I have also made it clear that I > will be happy to be proven wrong here. Since you're completely incapable of a small challenge, here's how you can do it: file: endian.c: === #include <stdio.h> union endian { short s; char c[sizeof(short)]; }; int main(void) { union endian endian; endian.s = 1; if (endian.c[0]) printf("LITTLEENDIAN"); else printf("BIGENDIAN"); return 0; } === gcc endian.c -o endian file: endiantest.c: === #include <stdio.h> int main(void) { #ifdef BIGENDIAN printf("Big Endian defined\n"); #elif defined LITTLEENDIAN printf("Little Endian defined\n"); #else printf("No endian defined\n");
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment