Talk:COMEFROM

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 
WikiProject Computer science (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
 

Untitled[edit]

I don't see any discussion here of the resemblance between block structured exception handling and COMEFROM. "Catch" clauses are very much like a "structured" cousin of COMEFROM, as the point from which control is transferred doesn't specify where it goes, and instead the point at which it arrives "catches" it.--74.104.131.76 15:48, 31 December 2006 (UTC)

Example[edit]

Isn't there something going on in the examples, where the variables "Solon" "Gfar" and "Ewell" (Solong, farewell) are defined, but elsewhere in the listing, and in the summary afterward, the variable becomes "Gear"? —Preceding unsigned comment added by 195.137.35.233 (talk) 14:14, 10 June 2009 (UTC)


Breakpoints[edit]

The most practical known use of a COMEFROM-like structure is as a breakpoint during debugging. One implementation of FORTRAN included it, under the name "AT", as a debugging aid, with dire warnings against using it in production code. In addition, many modern CPUs have hardware support for breakpoints.

Do these "hardware breakpoints" really act like COMEFROM, or are they some kind of "break" instruction that isn't at all like COMEFROM? The latter sounds much more likely to me... - furrykef (Talk at me) 08:03, 28 March 2007 (UTC)

They really do act like COMEFROM. The CPU has special debug registers which hold the addresses of instructions that should be made to trap. Any regular instruction can be made to trap, without needing to replace the instruction. An x86 supports 4 simultaneously. Most debuggers don't use them, because break instructions are easier and because the debug registers are best used for watching data. AlbertCahalan 04:09, 27 May 2007 (UTC)

SHARC example[edit]

For those who will surely doubt...

Yes, that's real assembly language for a real CPU. I know it looks like a bastard hybrid of C and FORTRAN. It's the kind of assembly language you get from people who design a CPU with hardware support for 6 simultaneous COMEFROMs. The SHARC is VLIW, so that crazy line with 3 math operations and two memory loads is also real... and executes with single clock cycle throughput.

BTW, SHARC also has two delay slots, word addressing, 48-bit instructions, and 40-bit floats. Anybody else think the designers were completely insane?

AlbertCahalan 04:24, 27 May 2007 (UTC)

Looks to me like the SHARC example is just a plain old Fortran-style DO loop. The fact that SHARC supports six nested hardware loops is irrelevant; I think we can agree that if that code is equivalent to a DO loop, then it's not equivalent to a COMEFROM statement (because COMEFROM is an esoteric and half-meaningless joke, while DO is not). What am I missing? --Quuxplusone (talk) 11:41, 4 January 2009 (UTC)

Exceptions (C++ sense)[edit]

I have always thought of exceptions (try... catch... throw) as essentially "COMEFROM" as on the throw you don't know where you're going to but on the catch you (can) know where you've come from. I must admit I have actually used this abhorrently where GOTO is considered harmful overmuch. I would add a little section about this but I think it would be regarded "original research"-- I don't think I have published these thoughts except in internal publications. Any thoughts?

SimonTrew (talk) 19:54, 4 February 2009 (UTC)

Aspect oriented programming?[edit]

I realize that 'comefrom' was intended as a joke, but somehow it bears a resemblance to the concepts of aspect oriented programming. Is there an AOP expert (or someone with more knowledge than me... which isn't much) :) out there that could perhaps comment on this? roe (talk) 07:38, 24 July 2009 (UTC)

Ruby example[edit]

The Ruby example implementation, aside from being redundant, is currently incorrect and should be removed. It cannot handle the case where a COME FROM may occur later in the program flow than the corresponding LABEL (it cannot jump "forwards"), which is clearly not a correct inverse of GOTO. —Preceding unsigned comment added by 86.9.3.250 (talk) 22:28, 10 November 2010 (UTC)

I'm missing mentioning the analogy of "COMEFROM" with POSIX-style setjmp/longjmp[edit]

The two functions are used as:

   jmp_buf jmp_id;
   setjmp(jmp_id);   /* establish a "COMEFROM" point here */
   /* do whatever - go wherever */
   longjmp(jmp_id);  /* redirect to wherever the previous setjmp() was */

which does seem quite close to the description ? — Preceding unsigned comment added by 82.210.249.81 (talk) 15:28, 30 June 2011 (UTC)