on goto
in [ASM]
|
From: Richard Bos on 11 May 2010 10:14 "Nathan Baker" <nathancbaker(a)gmail.com> wrote: > The CPU experiences a nightmare while executing HLL code. Perhaps there is > an instructive way for us to demonstrate this fact? <http://xkcd.com/371/> Richard
From: Juha Nieminen on 12 May 2010 08:56 In comp.lang.c++ Nathan Baker <nathancbaker(a)gmail.com> wrote: > > "Juha Nieminen" <nospam(a)thanks.invalid> wrote in message > news:4be50dcf$0$2544$7b1e8fa0(a)news.nbl.fi... >> In comp.lang.c++ io_x <a(a)b.c.invalid> wrote: >>> with assembly is possible to write recursions functions too >> >> That's like saying that C supports object-oriented programming. > > Of course it does! C certainly has support for data structures. See, that's another hilarious thing about obsessed C programmers: They don't even understand what "object-oriented programming" means or what does it mean for a language to support that. Think about it with a different example: While it's possible to handle arbitrary precision integers in C (for example by using a library like GMP), that doesn't mean the C programming language supports arbitrary precision integers. They are not part of the core language, or even its standard libraries, nor are they mentioned in any way or form in the official standard. Likewise the C language does not support object-oriented programming: It has no native support for classes with restricted compiler-enforced access rights, inheritance or dynamic binding / message dispatching. You can construct an environment which somewhat *simulates* this, but that doesn't mean the C language supports OOP any more than it supports eg. arbitrary precision integers. The main difference between a language which supports OOP directly and a language which does not is the amount of work the compiler does for the programmer.
From: wolfgang kern on 12 May 2010 08:37 Alexei A. Frounze explained the cause: <--q> "wolfgang kern" <nowh...(a)never.at> wrote: > Nathan Baker wrote: >>> Ok Nate, we had enough discussions on this matter since HLLs >>> entered our progamming world ... >>> We better give up arguing and let the 'faster' programmers >>> be proud of their 'maintainable/foolproof-readable' sources >>> which are awful detours with "abstraction layers" while the >>> few hardware freaks like me work on "really existing things" :) >> The CPU experiences a nightmare while executing HLL code. >> Perhaps there is an instructive way for us to demonstrate this fact? > Even we could try this one more time, I daubt that > 'fundamental' HLL-coders may listen at all. > The believe in their holy compilers seem to be very strong :) > I think demonstration of the bloated redundance isn't required, > disassemble whatsoever you find (windoze+lunix/app+sys) and > see as of immediate all the weird detours created by 'a tool'. > The few programmers who know both worlds may be aware and > create lesser bloated and faster code even with HLL. There are several reasons for what you call compiler-produced bloat: - copy-pasted code at the source level (can happen in asm too) - duplicate functionality and data in different parts of big applications (can happen in asm too) - overly complicated code (can happen in asm too) - dead code and data (can happen in asm too) - error handling code (you probably need it in asm too) - use of macros, inlining and templates (macros exist in asm too) - calling convention support code for interoperation, variable argument subroutines, exception handling and debugging (you may need or want some of them in asm too) - code alignment (you may need it in asm too) - inadequately chosen optimization switches or speed preference over size - global variables, including not tightly packed structures (you may want data alignment in asm too) So, some of it comes from bad or complex source code, some from the fact that applications are made from many different parts done independently by different people, some is dictated by the overall API design and some from how the compiler and linker are used. Then again, often times quickly making software is more important than making it fast or small or both. Depends on the business model, which you may be unable to change other than by quitting your employer and finding a "better" one or starting your own company or simply going self- employed. I'm just explaining how this bloat is possible and expected. Alex </--q> I fully agree with your notes, also ASM may use Libs and are often 'compiled' instead of designed. But even ASM may have to follow API calling conventions, we are free (in opposition to the poor C-coders) to avoid these 'oh so common' stack-copy-detours in our ASM-functions ... __ wolfgang
From: blmblm on 29 May 2010 15:30 In article <aa20c65b-4ea3-4132-a827-f3c0d653067a(a)24g2000yqy.googlegroups.com>, gwowen <gwowen(a)gmail.com> wrote: > On May 8, 1:39 am, Lie Ryan <lie.1...(a)gmail.com> wrote: > > > I've never heard of any programming languages that doesn't support > > recursion. > > Standard Fortran, prior to 1990. It was not a bad idea, given the > limited stack space on most machines, and the likelihood of stack > overflow. Especially given you can always do tail recursion by hand > (ObOnTopic: ... using goto.) That's funny; I was sure I'd used FORTRAN 77 compilers that supported recursion, though you did have to include something explicit to allow a subroutine to be used recursively. However, a quick Google search suggests that maybe this was a common but nonstandard extension. Hm! Anyway, as you say elsethread, it's been added, with so many other things. Fortran 90 and beyond are almost a different language! -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 29 May 2010 15:36
In article <4be62644$0$14116$703f8584(a)textnews.kpn.nl>, Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote: > Nick Keighley wrote: > > On 8 May, 17:46, Tim Streater <timstrea...(a)waitrose.com> wrote: > >> In article > >> <5dd9bdc8-4dc4-4537-84a0-885c4c92f...(a)l28g2000yqd.googlegroups.com>, > >> Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: > >>> On 8 May, 01:41, Lie Ryan <lie.1...(a)gmail.com> wrote: > > > > > >>>>> I've never heard of any programming languages that doesn't support > >>>>> recursion. > > [...] > >>> FORTRAN (in its original form), Coral-66 you had to use a special > >>> keyword to indicate a function was recursive. Some BASICs probably > >>> didn't alow recursion. But these all qualify as "ancient" (and maybe > >>> jocular!) > >> What FORTRAN are you referring to. I never saw it in any FORTRAN up to > >> 1978 (the last time I used FORTRAN). > > > > lost me. So far as I remember FORTRAN didn't have recursion. Am I > > wrong? Or are you saying even modern Fortran doesn't have recursion? > > If recursion does not exist, I will have to ditch quite a couple > of fortran programs. > There is only 1 hitch, you have to write a 3 line dummy routine, > to do the calling, so a calls b , b calls a. > fortran MS 5.1 and later. > Also Fortran77 for Riscos (arc 320 computer) And then there are systems on which this approach would almost surely fail spectacularly (as you may know -- just sayin'). In a long-ago job in which one of my responsibilities was finding and fixing bugs other people's FORTRAN, a particularly nasty one turned out to be the result of this kind of mutual recursion. If the system puts the return address for a call to a non-recursive subroutine in a fixed location, well .... I'm curious now about why A-calls-B-calls-A would work but simple A-calls-A would not. Is it a compiler issue? where the compiler won't allow the latter, but will allow the former? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. |