After looking at your example at
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c
I would like to comment:
the "goto done" in the first function is only necessary, because in C
the return statement
serves two purposes:
- setting the return value
- returning control to the caller
In Pascal, for example, the return value of a function is set by
assigning a value to the function name
(inside the function) and control is returned by reaching the end of the
function, or (in case of
Stanford Pascal and more recent Pascal dialects) the return statement
(which has no parameters etc.).
So there is a separation between the two purposes.
In Pascal then, there would be no need to branch to the end of the
function, because there is the
one and only place where you set the function result from the local temp
variable. Hence,
no need for a goto (no use case). The return statement would be at the
position where the
goto done is. The value is assigned to the function name instead of the
temp variable
(can be done at multiple places).
IIRC, this (the two purposes of the C return statement) has been
mentioned in one
of the videos posted by Peter Sylvester. This (IMO) is a flaw of the C
language.
There are others, for example that it's impossible to declare functions
inside of functions
(no true ALGOL block concept).
Kind regards
Bernd
Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the
opinions in these videos is the hackneyed nonsense about "goto
considered harmful". The original paper was misunderstood in that all
goto statements are harmful and brainwashed a generation. Some of
these videos present a trivial example using goto and refactor it
using if/ifelse. In programming languages without scope based cleanup
goto is not harmful. In fact it's leads to clean code as the branch
direction is always descending to a cleanup block. Happily for me, the
young guys I work with writing systems level Metal/C code haven't been
seduced by this dogmatic BS. Good C code uses goto statements as
opposed to heavily nested or superfluously functionally decomposed
routines. The IBM Openj9 JVM C code is a case in point
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c.
I challenge anybody to write better code without goto statements.
On 20/09/2022 5:46 pm, Peter Sylvester wrote:
Hi,
49 years ago I 'stumbled' over Simula 67 (see video 1), well, at the
university "informatik 1" course. I had gotten an Algol60 book given
to me by my math teacher 2 years earlier. The student a year older
learned PL/1. WE had an /168 and the Simula 67 system from the NCC
(you can find it on the CBTTAPE, the turnkey system and elsewhere.
To assembler: On error, you got a nicely formatted storage dump of
objects. One motivation
After two years and the first graduation (Vordiplom) with punched
cards etc (but using the MFT like a PC), a got a job at at the CS
research center GMD: MVS, TSO SPF, another universe. It would take
to much here to explain all the reason why I did a lot of assembler
(because of this I was able to work in an internship at the swiss
Colony Computing Center), but I always more than mildly disliked aka
hated the non structured way of assembled. My work was to write a
fast program to create microfiches (block letters, index pages). The
result were a set of structured programming macros (also on the
cbttape).
Later with UCLA/Mail, the formatting of "objects" on traces, dumps.
and stack of function. Just read the "assembler" code (CBTTAPE).
Anyway, here some nice videos.
https://www.youtube.com/watch?v=pH-q2m5sb04
actually, why is smalltalk so close to objective C. Because of a Byte
Magazine cover page.
https://www.youtube.com/watch?v=SFv8Wm2HdNM
https://www.youtube.com/watch?v=QM1iUe6IofM
https://www.youtube.com/watch?v=eEBOvqMfPoI
Some are provocative. There are many others. I really like "going
virtually" to these conferences.
https://www.youtube.com/watch?v=_mZBa3sqTrI&t=45s
Sorry for this side track
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
