- C p - 4 Updates
- Seems like the double * and double ** are put on stack in reverse order expected - 2 Updates
| Barry Schwarz <schwarzb@dqel.com>: Apr 19 03:17PM -0700 On Tue, 19 Apr 2016 12:04:50 -0700 (PDT), somurgeyunus@gmail.com wrote: >1. Construct your own library by generating .c and .h files. Your library should include the following functions: You do realize that C and C++ are two different languages? -- Remove del for email |
| red floyd <no.spam.here@its.invalid>: Apr 19 10:41PM -0700 > 1. sumOfIntegersDivisibleBy3 > 2. factorial > 3. power I have posted a complete solution for you at the following URL: https://www.cs.rit.edu/~mjh/docs/c++-faq/how-to-post.html#faq-5.2 |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 03:06AM -0700 On Wednesday, 20 April 2016 01:17:43 UTC+3, Barry Schwarz wrote: > wrote: > >1. Construct your own library by generating .c and .h files. Your library should include the following functions: > You do realize that C and C++ are two different languages? Perhaps, since it posted that first to comp.lang.c but got stock replies there. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 03:14AM -0700 > 1. Construct your own library by generating .c and .h files. Should the code generator (that makes described C code) be written in C++ or may you use some text-oriented language like Perl or Python? |
| Robert Wessel <robertwessel2@yahoo.com>: Apr 19 07:40PM -0500 On Tue, 19 Apr 2016 19:02:12 -0400, Jerry Stuckle >> I didn't say it either. >Then why would it be slow? The R13 calling convention has a great deal of unnecessary overhead, even if you don't need to allocate the save and parameter areas from the OS. First, you'll have to allocate them from someplace, and second passing parameters via the R1 list painful for the vast majority of short parameters that are passed by value. Then maintaining the linkagae is more expensive than necessary (while C++ does require a back chain in order to unwind exceptions, it does need the forward chain), and you're forced to save too many registers. In XPLink, for example, you can pass several parameters in registers, you don't need two areas to manage, there's no forward chain, and the number of registers saved is usually considerably less. If the R13 convention was a good one in general, people wouldn't spend so much time avoiding it. Even traditional assembler or HLL usage on S/360, et al, usually avoided that internally. Almost never did you see an internal subroutine call in an assembler program do the full save area thing (yes, there were time when it was appropriate). Likewise internal calls in Cobol and Fortran tended to use their own mechanism as well. That is, of course, true on many platforms, there's a standard ABI, but it's only followed at boundaries beteween components - many compilers will optimizse the calling convention at points where they can decide that following the stanbard ABI is not necesary (for example, if a routine is only called from inside a program). And that true even though most platforms "standard" ABI are not nearly as painful as the S/360 one. >> parameters and return values. >That depends on which compiler you are using. There is no "standard" >(as there is in the R13 save area standard). XPLink is a standard, it's not followed everywhere. There are (like on many platforms) a number of "standard" calling conventions on mainframes (the LE convention, the OS (R13) conventions plus a stack, the PL/I modification of the standard OS convention, etc.) The point, however, is that the notion that the S/360 R13 convention is most common inside C or C++ programs is wrong. |
| 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. |
| 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