Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Re: Fwd: Linux on a small memory PC
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Fwd: Linux on a small memory PC [message #415604 is a reply to message #415567] Tue, 26 July 2022 16:43 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:

> Smaller CAN be bigger. Find a niche you can LOVE.
>
> But if you just HAVE to have the biggest mini-mansion
> on the block and $125,000 matched Hiz/Herz SUVs and
> the gigantic loan payments that come with it ... well ...
> you may have to *WORK A HATEFUL JOB* for pointy-haired
> bosses ... sorry .........

But that's Success. Don't you want Success?

I've spent my entire career avoiding Success.
It's much more fun that way.

BTW on Peter Gabriel's album _So_, the lyrics for
_Big Time_ are accompanied by the note "suc cess".

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415605 is a reply to message #415563] Tue, 26 July 2022 16:43 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:

> On 7/25/22 4:55 PM, Peter Flass wrote:
>
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>> downstream consequences hmmm ??? ;-)
>>
>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>> try to figure out what the heck you were trying to do. The more “concise”
>> a language is, the more write-only it tends to be.
>
> THAT'S why 60-75% of my programs are expository COMMENTS
> and little TUTORIALS. YOU can EXPLAIN the code a LOT
> better than any code can explain itself.
>
> Even my ASM ... every line has a comment, an ongoing
> narrative of what's happening and why. Based on that
> you could translate it into a dozen higher-level
> languages.

I started doing exactly that in assembly language, and still do it in C.

> And then I see "examples" with 200 lines of 'C' or
> whatever with like THREE cryptic comments. The rest
> is apparently all Magic ....

"My code is so readable it doesn't need comments."

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415606 is a reply to message #415570] Tue, 26 July 2022 16:43 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:

> For IBM mainframes the COBOL compiler is going to be way more efficient
> than C because the COBOL compiler is way more likely to be using packed
> decimal.

As long as you're referring to data fields, that's true.
But I once knocked 30% off a program's execution time by
simply changing all subscripts from COMP-3 (packed decimal)
to COMP-4 (binary). (The original author obviously had
no real-world experience.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415607 is a reply to message #415596] Tue, 26 July 2022 16:43 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, John Levine <johnl@taugh.com> wrote:

> According to 25B.Z959 <25B.Z959@nada.net>:
>
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> i += 2; // Add 1 to i.

Well, it might have done so in the original version -
which is why keeping comments up to date is vital.

(And yes, comments that trivial are a waste of time.
But that's another topic.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415608 is a reply to message #415568] Tue, 26 July 2022 16:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> > Sometimes that IS a factor ... you have to have people who
>>>> > can write it. But 1990 ... IMHO it should have been 'C'.
>>>> >
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>> language. Things
>>>> that are so dimple in COBOL, like moving a character string with blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>> C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>>
>> And why do you think that?
>>
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you are,
> on an abstract level. However, modern C compilers understands what this
> is, and will in fact insert the required code directly in the
> instruction stream, which, again depending on the hardware, might end up
> being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even sillier.
>

Better for what? C is, or at least used to be, excellent at generating very
tight code with little overhead. From what I’ve seen, I believe the
overhead has crept back in. COBOL is excellent for programs that might not
need to be the fastest, but are expected to be running for DECADES and
maintained by a lot of different people of wildly different skill levels.

If I were writing an OS, I’s choose C over COBOL (actually, I’d choose PL/I
but that’s another argument). If I were writing a payroll system, COBOL
might be a better choice.

--
Pete
Re: COBOL and tricks [message #415609 is a reply to message #415570] Tue, 26 July 2022 16:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Dan Espen <dan1espen@gmail.com> wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> On 2022-07-26 01:42, Dan Espen wrote:
>>> Johnny Billquist <bqt@softjar.se> writes:
>>>
>>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> > 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> >> Sometimes that IS a factor ... you have to have people who
>>>> >> can write it. But 1990 ... IMHO it should have been 'C'.
>>>> >>
>>>> >
>>>> > IMNSHO, COBOL. C is a terrible language for those types of
>>>> language. Things
>>>> > that are so dimple in COBOL, like moving a character string with blank
>>>> > fill, or formatting numeric output, requires calling subroutines in
>>>> C, and
>>>> > lack of length checking on string moves is a recipe for disaster.
>>>> This is one of the weirder arguments I've ever seen:
>>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>>> Not to mention it's a function, and not a subroutine. Any claim of
>>>> "used the language quite a bit" sounds hollow after that.
>>>>
>>>> A statement to move a character string in COBOL will in the end be a
>>>> subroutine call as well.
>>> And why do you think that?
>>> I've sure seen lots of COBOL MOVE instructions generate a single
>>> hardware instruction.
>>
>> Depends on the compiler and hardware, and so on...
>> Which actually leads to the point that the same is true in C.
>> You might think you are calling a function like strncpy(). And you
>> are, on an abstract level. However, modern C compilers understands
>> what this is, and will in fact insert the required code directly in
>> the instruction stream, which, again depending on the hardware, might
>> end up being a single instruction.
>>
>> So in which way was COBOL better than C? In the end, claiming
>> superiority of a language based on that one have a function, while the
>> other have it as a statement is about as silly an argument as I have
>> ever seen. And all the extra claims to support that view are even
>> sillier.
>
> This is all true, an IBM mainframe C compiler CAN generate a single
> instruction for a memcpy or strncpy. Providing the compiler can tell
> the length of the move at compile time. Something that is a lot more
> likely for COBOL than C.
>
> For IBM mainframes the COBOL compiler is going to be way more efficient
> than C because the COBOL compiler is way more likely to be using packed
> decimal.
>
>

XLC has functions for handling packed decimal. I don’t know about current
mainframe C.

--
Pete
Re: COBOL and tricks [message #415610 is a reply to message #415574] Tue, 26 July 2022 16:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Tue, 26 Jul 2022 14:13:56 +0100
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> C is the exact opposite, terse, machine level assembler but faster
>>> coded.
>>
>> “Assembler” is a terrible mental model for C.
>>
>> richard@sfere:~/junk$ cat t.c
>> int f(int *ptr) {
>> int r = *ptr;
>
> If ptr is 0 this is undefined behaviour aka probably SEGV.

The programmer makes assumptions based on what he/she knows. Presumably the
original author might “know” that ptr will never be zero (previously
tested, data would not allow it, etc.) This is why maintenance is such a
minefield. I have been bitten by my own code when I changed it years after
originally written.

Actually, I wouldn’t WANT the compiler to test for zero here. If you want
it, do it yourself.

--
Pete
Re: COBOL and tricks [message #415611 is a reply to message #415580] Tue, 26 July 2022 16:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Pancho <Pancho.Jones@proton.me> wrote:
> On 26/07/2022 16:20, The Natural Philosopher wrote:
>> On 26/07/2022 15:52, Richard Kettlewell wrote:
>>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> > The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> >> C is the exact opposite, terse, machine level assembler but faster
>>>> >> coded.
>>>> >
>>>> > “Assembler” is a terrible mental model for C.
>>>> >
>>>> >      richard@sfere:~/junk$ cat t.c
>>>> >      int f(int *ptr) {
>>>> >        int r = *ptr;
>>>>
>>>>     If ptr is 0 this is undefined behaviour aka probably SEGV.
>>>
>>> Please see the remarks you snipped. If *ptr faults then the likely
>>> outcome is a crash; but in some environments that does not happen.
>>>
>>>> >        if(!ptr)
>>>>
>>>>     Did you mean !*ptr ?
>>>
>>> No, I did not.
>>>
>>>> >          return 0;
>>>> >        return r;
>>>>
>>>>     Or is it counting on ptr not really being followed until here ?
>>>
>>> No, the code is buggy (the indirection and the test are the wrong way
>>> around). But it’s a bug that happened in real life and the outcome is
>>> not someone working with the ‘portable assembler’ mental model of C
>>> would expect.
>>
>> Once you introduce a bug and have a buggy compiler, that's exactly what
>> you do expect.
>>
>> Carrying a mental model in assembler, what that code is , is to lead the
>> contents of a reference which may be null, then test if the reference is
>> actually null, and pass that reference contents or null back.
>> At assembly level that is pure nonsense. There is no point in testing a
>> pointer for null if you have already referenced it.
>>
>> The fact that you have been able to reference it without a segfault
>> shows it is probably not null.
>
> I think the point was that some OS (or is it CPU architecture) allows
> you to read from the NULL memory address. I've no idea which one, but
> presumably one does.
>
> If the read from the NULL address throws a fault, then the C and
> assembler will be equivalent.
>
>> So the first point is that the actual code is crap. Written by someone
>> who didn't know what they were doing.
>> The second point is that the compiler is certainly behaving in a
>> questionable manner too.
>
> C says the operation is undefined. I don't use C. Just thinking about it
> makes me feel queezy.
>

In a lot of cases, the contents of low memory, including address 0, are
readable. In MVS (etc.) low memory is the Prefixed Storage Area (PSA) which
is a useful control block. Some, or all?, Unices don’t map page zero, so
you get a SIGSEGV trying to access it, but this isn’t universally true.

--
Pete
Re: COBOL and tricks [message #415612 is a reply to message #415539] Tue, 26 July 2022 16:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Vir Campestris

On 25/07/2022 21:55, Peter Flass wrote:
> No, COBOL is for the NEXT poor bastard who has to look at your code and
> try to figure out what the heck you were trying to do. The more “concise” a
> language is, the more write-only it tends to be.

Ah, you've seen APL then?

Andy
Re: COBOL and tricks [message #415613 is a reply to message #415607] Tue, 26 July 2022 16:53 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Vir Campestris

On 26/07/2022 21:43, Charlie Gibbs wrote:
> On 2022-07-26, John Levine <johnl@taugh.com> wrote:
>
>> According to 25B.Z959 <25B.Z959@nada.net>:
>>
>>> Even my ASM ... every line has a comment, an ongoing
>>> narrative of what's happening and why. Based on that
>>> you could translate it into a dozen higher-level
>>> languages.
>>
>> i += 2; // Add 1 to i.
>
> Well, it might have done so in the original version -
> which is why keeping comments up to date is vital.
>
> (And yes, comments that trivial are a waste of time.
> But that's another topic.)
>
The useful comments don't say _what_ you're doing, they say _why_.

Andy
Re: COBOL and tricks [message #415616 is a reply to message #415596] Tue, 26 July 2022 16:57 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
John Levine <johnl@taugh.com> wrote:
> According to 25B.Z959 <25B.Z959@nada.net>:
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> i += 2; // Add 1 to i.
>

For some values of one ;-)

--
Pete
Re: COBOL and tricks [message #415617 is a reply to message #415605] Tue, 26 July 2022 16:57 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/25/22 4:55 PM, Peter Flass wrote:
>>
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>
>>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>>> downstream consequences hmmm ??? ;-)
>>>
>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>> try to figure out what the heck you were trying to do. The more “concise”
>>> a language is, the more write-only it tends to be.
>>
>> THAT'S why 60-75% of my programs are expository COMMENTS
>> and little TUTORIALS. YOU can EXPLAIN the code a LOT
>> better than any code can explain itself.
>>
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> I started doing exactly that in assembly language, and still do it in C.
>
>> And then I see "examples" with 200 lines of 'C' or
>> whatever with like THREE cryptic comments. The rest
>> is apparently all Magic ....
>
> "My code is so readable it doesn't need comments."
>

I comment most lines, and include the text of the spec I’m working from as
a block comment where appropriate.

--
Pete
Re: COBOL and tricks [message #415618 is a reply to message #415581] Tue, 26 July 2022 16:58 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Vir Campestris

On 26/07/2022 17:17, Scott Lurndal wrote:
> Pancho <Pancho.Jones@proton.me> writes:
>> On 26/07/2022 16:20, The Natural Philosopher wrote:
>>> On 26/07/2022 15:52, Richard Kettlewell wrote:
>
>>> The fact that you have been able to reference it without a segfault
>>> shows it is probably not null.
>>
>> I think the point was that some OS (or is it CPU architecture) allows
>> you to read from the NULL memory address. I've no idea which one, but
>> presumably one does.
>
> The legacy BSD operating systems marked page zero of the virtual address
> space as READ-ONLY and initialized the entire page with zeros. Trying
> to store through a NULL pointer would fault, but loads would return zero.
>
> Took a fair amount of work to fix BSD utilities to work on System V due
> to this.
>
> For microcontrollers etc that don't have virtual memory, address zero
> was always legal.
>
> In early processors, there were often registers located in the first
> page of memory (e.g. the autoincrement memory locations in the PDP-8).

The first system I learned assembler on was a DECSystem10. That had the
registers mapped into the first 16 memory addresses, so an access via a
null pointer would have given the the contents of the first register.

OTOH its memory was all 36 bit words, with magic to access strings. I
don't think C would have worked at all well.

Andy
Re: COBOL and tricks [message #415624 is a reply to message #415610] Tue, 26 July 2022 17:20 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Tue, 26 Jul 2022 13:49:44 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Tue, 26 Jul 2022 14:13:56 +0100
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> C is the exact opposite, terse, machine level assembler but faster
>>>> coded.
>>>
>>> “Assembler” is a terrible mental model for C.
>>>
>>> richard@sfere:~/junk$ cat t.c
>>> int f(int *ptr) {
>>> int r = *ptr;
>>
>> If ptr is 0 this is undefined behaviour aka probably SEGV.
>
> The programmer makes assumptions based on what he/she knows. Presumably
> the original author might “know” that ptr will never be zero (previously

Programmer tests ptr for 0 in the next statement. Buggy code!

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415625 is a reply to message #415612] Tue, 26 July 2022 17:26 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Tue, 26 Jul 2022 21:52:32 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> On 25/07/2022 21:55, Peter Flass wrote:
>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>> try to figure out what the heck you were trying to do. The more
>> “concise” a language is, the more write-only it tends to be.
>
> Ah, you've seen APL then?

The most unreadable language yet has to be whitespace:

https://en.wikipedia.org/wiki/Whitespace_(programming_language)

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415626 is a reply to message #415613] Tue, 26 July 2022 17:21 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Tue, 26 Jul 2022 21:53:36 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The useful comments don't say _what_ you're doing, they say _why_.

This!

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415627 is a reply to message #415618] Tue, 26 July 2022 17:19 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Tue, 26 Jul 2022 21:58:53 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The first system I learned assembler on was a DECSystem10. That had the
> registers mapped into the first 16 memory addresses, so an access via a
> null pointer would have given the the contents of the first register.
>
> OTOH its memory was all 36 bit words, with magic to access strings. I
> don't think C would have worked at all well.

You might be surprised - it seems gcc was got working on it a
couple of decades ago.

http://pdp10.nocrew.org/gcc/

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415630 is a reply to message #415606] Tue, 26 July 2022 20:15 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:
>
>> For IBM mainframes the COBOL compiler is going to be way more efficient
>> than C because the COBOL compiler is way more likely to be using packed
>> decimal.
>
> As long as you're referring to data fields, that's true.
> But I once knocked 30% off a program's execution time by
> simply changing all subscripts from COMP-3 (packed decimal)
> to COMP-4 (binary). (The original author obviously had
> no real-world experience.)

Now the right solution is

USAGE IS INDEX

Of course you don't use packed decimal for indexes. USAGE DISPLAY is no
good either. But early on most of us knew to use COMP before usage
index was invented.


--
Dan Espen
Re: COBOL and tricks [message #415631 is a reply to message #415609] Tue, 26 July 2022 20:25 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
Peter Flass <peter_flass@yahoo.com> writes:

> Dan Espen <dan1espen@gmail.com> wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-26 01:42, Dan Espen wrote:
>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>
>>>> > On 2022-07-24 00:23, Peter Flass wrote:
>>>> >> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> >>> Sometimes that IS a factor ... you have to have people who
>>>> >>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>> >>>
>>>> >>
>>>> >> IMNSHO, COBOL. C is a terrible language for those types of
>>>> > language. Things
>>>> >> that are so dimple in COBOL, like moving a character string with blank
>>>> >> fill, or formatting numeric output, requires calling subroutines in
>>>> > C, and
>>>> >> lack of length checking on string moves is a recipe for disaster.
>>>> > This is one of the weirder arguments I've ever seen:
>>>> > "requires calling a subroutine in C". As if that somehow is a problem?
>>>> > Not to mention it's a function, and not a subroutine. Any claim of
>>>> > "used the language quite a bit" sounds hollow after that.
>>>> >
>>>> > A statement to move a character string in COBOL will in the end be a
>>>> > subroutine call as well.
>>>> And why do you think that?
>>>> I've sure seen lots of COBOL MOVE instructions generate a single
>>>> hardware instruction.
>>>
>>> Depends on the compiler and hardware, and so on...
>>> Which actually leads to the point that the same is true in C.
>>> You might think you are calling a function like strncpy(). And you
>>> are, on an abstract level. However, modern C compilers understands
>>> what this is, and will in fact insert the required code directly in
>>> the instruction stream, which, again depending on the hardware, might
>>> end up being a single instruction.
>>>
>>> So in which way was COBOL better than C? In the end, claiming
>>> superiority of a language based on that one have a function, while the
>>> other have it as a statement is about as silly an argument as I have
>>> ever seen. And all the extra claims to support that view are even
>>> sillier.
>>
>> This is all true, an IBM mainframe C compiler CAN generate a single
>> instruction for a memcpy or strncpy. Providing the compiler can tell
>> the length of the move at compile time. Something that is a lot more
>> likely for COBOL than C.
>>
>> For IBM mainframes the COBOL compiler is going to be way more efficient
>> than C because the COBOL compiler is way more likely to be using packed
>> decimal.
>
> XLC has functions for handling packed decimal. I don’t know about current
> mainframe C.

Back when I was working the situation was that C had one way of doing
it, C++ had another. Neither was a clean solution in my opinion.


--
Dan Espen
Re: COBOL and tricks [message #415634 is a reply to message #415596] Tue, 26 July 2022 22:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/26/22 3:38 PM, John Levine wrote:
> According to 25B.Z959 <25B.Z959@nada.net>:
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> i += 2; // Add 1 to i.

Um ... that'd add TWO to i .......

i++ ; add 1 to i ... ++i++ might add two, depending
on the compiler.

(Intel 8051 ... assume 'i' is ushort value at address 0x0100)

MOV 0x0100,a ... copy contents of address 0x100 to accumulator
INC a ... increment accumulator by one
MOV a, 0x0100 ... copy accumulator to address 0x0100

- OR JUST -

INC 0x0100 ... increment byte value found at 0x0100,
... kinda actually does the above three lines,
... but leaves accumulator as-is.

Gets more complicated incrementing an integer var, gotta
ADD so the overflow flag comes into play. INC does not
affect the overflow flag, it just rolls-over to 0x00 if
you inc an 0xFF
Re: COBOL and tricks [message #415635 is a reply to message #415613] Tue, 26 July 2022 22:45 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/26/22 4:53 PM, Vir Campestris wrote:
> On 26/07/2022 21:43, Charlie Gibbs wrote:
>> On 2022-07-26, John Levine <johnl@taugh.com> wrote:
>>
>>> According to 25B.Z959 <25B.Z959@nada.net>:
>>>
>>>>    Even my ASM ... every line has a comment, an ongoing
>>>>    narrative of what's happening and why. Based on that
>>>>    you could translate it into a dozen higher-level
>>>>    languages.
>>>
>>>     i += 2;    // Add 1 to i.
>>
>> Well, it might have done so in the original version -
>> which is why keeping comments up to date is vital.
>>
>> (And yes, comments that trivial are a waste of time.
>> But that's another topic.)
>>
> The useful comments don't say _what_ you're doing, they say _why_.


'Zactly ... it needs to be a 'narrative' - both WHAT and WHY.
Doesn't matter if it's ASM or COBOL or FORTRAN or Python. If
you or anybody would EVER need to go back and tweak the pgm
it really NEEDS serious commenting. Alas it's kinda RARE to
see this ..... the old "Well *I* know what it's all about NOW"
attitude. Wait a couple years until the boss decides your form
needs some new data fields or entry box #7 moved 10 spaces to
the right 'cause it would 'look nicer' .... :-)

Think of the actual code as 'shorthand' for the story you're
writing whether it's Shakespeare, or "See Spot run !" ....
Re: COBOL and tricks [message #415639 is a reply to message #415605] Tue, 26 July 2022 22:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/26/22 4:43 PM, Charlie Gibbs wrote:
> On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/25/22 4:55 PM, Peter Flass wrote:
>>
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>
>>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>>> downstream consequences hmmm ??? ;-)
>>>
>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>> try to figure out what the heck you were trying to do. The more “concise”
>>> a language is, the more write-only it tends to be.
>>
>> THAT'S why 60-75% of my programs are expository COMMENTS
>> and little TUTORIALS. YOU can EXPLAIN the code a LOT
>> better than any code can explain itself.
>>
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> I started doing exactly that in assembly language, and still do it in C.
>
>> And then I see "examples" with 200 lines of 'C' or
>> whatever with like THREE cryptic comments. The rest
>> is apparently all Magic ....
>
> "My code is so readable it doesn't need comments."


There's an old joke about a college prof (and a friend
of mine had one JUST like it) where the prof slams down
five lines of ultra-dense next-level math on the blackboard
then kinda half turns to the class and says "So, obviously ..."
Re: Fwd: Linux on a small memory PC [message #415640 is a reply to message #415348] Tue, 26 July 2022 23:19 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 25B.Z959

On 7/20/22 6:41 PM, J. Clarke wrote:
> On Mon, 18 Jul 2022 21:26:23 -0400, "25B.Z959" <25B.Z959@nada.net>
> wrote:
>
>> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>>> [Cross-posted to alt.folklore.computers]
>>>
>>> On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>> > On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> >
>>>> >> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>> >>
>>>> >>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>> >>>
>>>> >>>> Fortunately, few are so cheap to be using 2-digit dates
>>>> >>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>> >>>> little space, easier calx.
>>>> >>>
>>>> >>> There you go, true to form. Now people use 2 digit dates because
>>>> >>> they are cheap.
>>>> >>
>>>> >> You are neglecting Computers Past ..... low speed, low
>>>> >> capacity. You simplified calx, you squeezed-down the data anywhere
>>>> >> you could. I know, I had to do it.
>>>> >
>>>> > Me too. My first job was in an all-card shop. To squeeze things onto
>>>> > an 80-column card, we stored dates in 5 columns as ddmmy. That's
>>>> > right, we only kept the last digit of the year. I started there in
>>>> > 1970, and one of my first assignments was to go through all report
>>>> > programs and change the '6' they inserted in front of the year to '7'.
>>>>
>>>> In an all card shop having more than 1 card for a logical record is a
>>>> problem. Not insurmountable but difficult. I've heard the one digit
>>>> year story in that context but never had to deal with it.
>>>
>>> We used two cards for customer name data, but they didn't have dates
>>> in them, just long names. You're right, having more than one card
>>> for a logical record is a pain in the ass. I use the present tense
>>> because I'm still faced with such files today.
>>
>>
>> Yep - the past IS present ... old records never die, they
>> just become more inconvenient. :-)
>>
>> Amazing how many institutions STILL run COBOL apps writ
>> during the 60s by the guys with skinny ties. They work
>> very well, they're too expensive to re-do, so ....
>>
>> There's probably a COBOL->C++ or JAVA translator out
>> there somewhere ... but money's so tight these days
>> and so many of those legacy apps are so super-critical
>> that they just can't/won't.
>
> And now some poor schmuck in India has to deal with it all.


You can hear them leafing through their manuals as they
ask irrelevant questions ......

I once was looking through one of those sites that list
unsecured webcams (and you'd be amazed how many). One
of them was a tech-support main room in Bangalore. At
(N.American) night you'd see them all lined up at their
PCs ... but N.American DAY ... they all had a little
mat and slept packed-in on the floor. Really.
Re: COBOL and tricks [message #415643 is a reply to message #415591] Wed, 27 July 2022 06:36 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 26/07/2022 17:53, Andy Walker wrote:
> Whether a compiler "should" assume that is a matter of opinion.
> But the compiler is /entitled/ to assume that, because if it is null then
> the behaviour on dereferencing was undefined,

Why is that? memory address of 0 is a valid memory address. At least in
hardware terms.
Does the C language enforce that memory at (page) address 0 is
unaddressable?


--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone
Re: COBOL and tricks [message #415644 is a reply to message #415605] Wed, 27 July 2022 06:39 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 26/07/2022 21:43, Charlie Gibbs wrote:
> On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/25/22 4:55 PM, Peter Flass wrote:
>>
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>
>>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>>> downstream consequences hmmm ??? ;-)
>>>
>>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>>> try to figure out what the heck you were trying to do. The more “concise”
>>> a language is, the more write-only it tends to be.
>>
>> THAT'S why 60-75% of my programs are expository COMMENTS
>> and little TUTORIALS. YOU can EXPLAIN the code a LOT
>> better than any code can explain itself.
>>
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> I started doing exactly that in assembly language, and still do it in C.
>
>> And then I see "examples" with 200 lines of 'C' or
>> whatever with like THREE cryptic comments. The rest
>> is apparently all Magic ....
>
> "My code is so readable it doesn't need comments."
>
I am in between. Typically I will head a block of code with an
explanation of what it is supposed to do.

I wont bother much in between unless that code looks cryptic to me, and
I try to make it not so. Bearing in mind that compiler optimisation
means you needn't code for speed at source level, but for clarity.


--
Microsoft : the best reason to go to Linux that ever existed.
Re: COBOL and tricks [message #415645 is a reply to message #415643] Wed, 27 July 2022 07:28 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Wed, 27 Jul 2022 11:36:37 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 26/07/2022 17:53, Andy Walker wrote:
>> Whether a compiler "should" assume that is a matter of opinion.
>> But the compiler is /entitled/ to assume that, because if it is null
>> then the behaviour on dereferencing was undefined,
>
> Why is that? memory address of 0 is a valid memory address. At least in
> hardware terms.

However it usually isn't an accessible one in a protected memory
environment.

> Does the C language enforce that memory at (page) address 0 is
> unaddressable?

No, it simply states that the behaviour of a program is undefined
(by the C standard) once it attempts to access memory that hasn't been
allocated by one of the documented mechanisms in the C standard. What
happens depends on the platform and the compiler.

If you're writing code for a platform where you know what that
behaviour will be and it is the behaviour you want then C will not get in
your way (your compiler might but it should be persuadable) - but you are
warned that the code may behave differently on a different platform.

Note that the C standard does technically allow the compiler or the
compiled program to execute the author but as far as I know this option has
never been implemented - let me know if you find otherwise.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: COBOL and tricks [message #415646 is a reply to message #415643] Wed, 27 July 2022 08:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Andy Walker

On 27/07/2022 11:36, The Natural Philosopher wrote:
[I wrote:]
>> But the compiler is /entitled/ to assume that, because if it is>> null then the behaviour on dereferencing was undefined,
> Why is that? memory address of 0 is a valid memory address. At least
> in hardware terms.

Whether or not that is true depends on your hardware and what
pages [on systems where that is meaningful] have been allocated. But,
rather ...

> Does the C language enforce that memory at (page) address 0 is unaddressable?

... C enforces that 0, as a pointer, is a null pointer and cannot
properly be dereferenced [it can be used for other purposes]. See the C
standard, eg N1570 [C11 -- other C standards are available, but they
haven't changed much in this area over the decades]:

6.3.2.3.3:
" An integer constant expression with the value 0, or such an expression
" cast to type void *, is called a null pointer constant. If a null
" pointer constant is converted to a pointer type, the resulting pointer,
" called a null pointer, is guaranteed to compare unequal to a pointer
" to any object or function. "

and 6.5.3.2.4:
" The unary * operator denotes indirection. ... If an invalid value has
" been assigned to the pointer, the behavior of the unary * operator is
" undefined.[footnote 102] "

where footnote 102 says:
" Among the invalid values for dereferencing a pointer by the unary *
" operator are a null pointer, an address inappropriately aligned for
" the type of object pointed to, and the address of an object after
" the end of its lifetime. "

Whether a null pointer actually "points to address 0" is up to compiler
magic to sort out. After all, the high-level language programmer is not
expected to know where in storage the objects used by the program reside.
Note that the result of dereferencing a null pointer is undefined, rather
than, for example, being defined to halt the program with an error; you
may get away with it, but it's still a bug, and therefore a disaster
waiting to happen.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Kotzwara
Re: COBOL and tricks [message #415647 is a reply to message #415643] Wed, 27 July 2022 09:20 Go to previous messageGo to next message
Arne Luft is currently offline  Arne Luft
Messages: 321
Registered: March 2012
Karma: 0
Senior Member
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 26/07/2022 17:53, Andy Walker wrote:
>> Whether a compiler "should" assume that is a matter of opinion.
>> But the compiler is /entitled/ to assume that, because if it is null then
>> the behaviour on dereferencing was undefined,
>
> Why is that? memory address of 0 is a valid memory address. At least
> in hardware terms.

You’re still thinking about C as ‘portable assembler’.

> Does the C language enforce that memory at (page) address 0 is
> unaddressable?

It’s not about what it enforces; it’s about what it doesn’t enforce. In
this case, it places no constraints on the implementation’s behavior
when a null pointer (or any other kind of invalid pointer) is
dereferenced. Modern implementations exploit this absence of constraints
in their code generation.

--
https://www.greenend.org.uk/rjk/
Re: COBOL and tricks [message #415648 is a reply to message #415630] Wed, 27 July 2022 09:48 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Dan Espen <dan1espen@gmail.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> For IBM mainframes the COBOL compiler is going to be way more efficient
>>> than C because the COBOL compiler is way more likely to be using packed
>>> decimal.
>>
>> As long as you're referring to data fields, that's true.
>> But I once knocked 30% off a program's execution time by
>> simply changing all subscripts from COMP-3 (packed decimal)
>> to COMP-4 (binary). (The original author obviously had
>> no real-world experience.)
>
> Now the right solution is
>
> USAGE IS INDEX
>
> Of course you don't use packed decimal for indexes.

On IBM machines, that's true. Not true on Burroughs machines,
where non-BCD is far more costly (there are only two binary
instructions, B2D and D2B that convert back and forth, primarily
used by the OS to compute binary disk block numbers for the
disk/pack hardware).
Re: COBOL and tricks [message #415649 is a reply to message #415634] Wed, 27 July 2022 09:51 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/26/22 3:38 PM, John Levine wrote:
>> According to 25B.Z959 <25B.Z959@nada.net>:
>>> Even my ASM ... every line has a comment, an ongoing
>>> narrative of what's happening and why. Based on that
>>> you could translate it into a dozen higher-level
>>> languages.
>>
>> i += 2; // Add 1 to i.
>
> Um ... that'd add TWO to i .......

Um, the point was that over time the comments often
no longer reflect the code, as the code gets updated
and the programmer doesn't update the comment. Granted
it's more likely to occur when the comment -isn't- on the
same line as the code to which the comment applies.
Re: COBOL and tricks [message #415650 is a reply to message #415648] Wed, 27 July 2022 10:14 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
scott@slp53.sl.home (Scott Lurndal) writes:

> Dan Espen <dan1espen@gmail.com> writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> For IBM mainframes the COBOL compiler is going to be way more efficient
>>>> than C because the COBOL compiler is way more likely to be using packed
>>>> decimal.
>>>
>>> As long as you're referring to data fields, that's true.
>>> But I once knocked 30% off a program's execution time by
>>> simply changing all subscripts from COMP-3 (packed decimal)
>>> to COMP-4 (binary). (The original author obviously had
>>> no real-world experience.)
>>
>> Now the right solution is
>>
>> USAGE IS INDEX
>>
>> Of course you don't use packed decimal for indexes.
>
> On IBM machines, that's true. Not true on Burroughs machines,
> where non-BCD is far more costly (there are only two binary
> instructions, B2D and D2B that convert back and forth, primarily
> used by the OS to compute binary disk block numbers for the
> disk/pack hardware).

So, Burroughs machines use decimal numbers as indexes?
They must have decimal memory addressing too.

--
Dan Espen
Re: COBOL and tricks [message #415654 is a reply to message #415650] Wed, 27 July 2022 11:20 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Dan Espen <dan1espen@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Dan Espen <dan1espen@gmail.com> writes:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:
>>>>
>>>> > For IBM mainframes the COBOL compiler is going to be way more efficient
>>>> > than C because the COBOL compiler is way more likely to be using packed
>>>> > decimal.
>>>>
>>>> As long as you're referring to data fields, that's true.
>>>> But I once knocked 30% off a program's execution time by
>>>> simply changing all subscripts from COMP-3 (packed decimal)
>>>> to COMP-4 (binary). (The original author obviously had
>>>> no real-world experience.)
>>>
>>> Now the right solution is
>>>
>>> USAGE IS INDEX
>>>
>>> Of course you don't use packed decimal for indexes.
>>
>> On IBM machines, that's true. Not true on Burroughs machines,
>> where non-BCD is far more costly (there are only two binary
>> instructions, B2D and D2B that convert back and forth, primarily
>> used by the OS to compute binary disk block numbers for the
>> disk/pack hardware).
>
> So, Burroughs machines use decimal numbers as indexes?
> They must have decimal memory addressing too.

Yes. Memory was decimally addressed to the digit (nibble). A very
easy machine to debug on, you very seldom needed to work in any
base other than ten.
Re: COBOL and tricks [message #415655 is a reply to message #415645] Wed, 27 July 2022 13:50 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 27/07/2022 12:28, Ahem A Rivet's Shot wrote:
> Note that the C standard does technically allow the compiler or the
> compiled program to execute the author
That sounds nasty


--
No Apple devices were knowingly used in the preparation of this post.
Re: COBOL and tricks [message #415656 is a reply to message #415646] Wed, 27 July 2022 14:09 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 27/07/2022 13:01, Andy Walker wrote:
> After all, the high-level language programmer is not
> expected to know where in storage the objects used by the program reside.

When you are programming chips with no paging and memory mapped IO you
realise that C is not a 'high level language'

As I said, despite Richards assertions to the contrary, it is a fast way
to write assembler in an 8 or 16 bit microcontroller environment.
It has all the right keywords for bitwise operations, it can effectively
'peek' and 'poke' physical RAM locations for I/O purposes. The only time
I needed to drop to assembler was to write a multitasking executive, to
access Intel type I/O instructions, or write a wrapper for interrupts.

It has all the right tools for comms work, where the header on a byte
stream completely changes the nature and the data size of what follows.
Impossible in some languages without declaring vast clumsy unions.

--
No Apple devices were knowingly used in the preparation of this post.
Re: COBOL and tricks [message #415657 is a reply to message #415647] Wed, 27 July 2022 14:10 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
Senior Member
On 27/07/2022 14:20, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 26/07/2022 17:53, Andy Walker wrote:
>>> Whether a compiler "should" assume that is a matter of opinion.
>>> But the compiler is /entitled/ to assume that, because if it is null then
>>> the behaviour on dereferencing was undefined,
>>
>> Why is that? memory address of 0 is a valid memory address. At least
>> in hardware terms.
>
> You’re still thinking about C as ‘portable assembler’.
It is.

>
>> Does the C language enforce that memory at (page) address 0 is
>> unaddressable?
>
> It’s not about what it enforces; it’s about what it doesn’t enforce. In
> this case, it places no constraints on the implementation’s behavior
> when a null pointer (or any other kind of invalid pointer) is
> dereferenced. Modern implementations exploit this absence of constraints
> in their code generation.
>
Then the coder was as I said an idiot for dereferencing a pointer that
was clearly expected to possibly be null
]

--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.
Re: COBOL and tricks [message #415658 is a reply to message #415618] Wed, 27 July 2022 14:10 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The first system I learned assembler on was a DECSystem10. That had the
> registers mapped into the first 16 memory addresses, so an access via a
> null pointer would have given the the contents of the first register.

In addition to the registers, the Univac 9300 stored things like the
program counter and the currently-executing instruction in low memory.
I came up with all sorts of fun ways to write a one-instruction loop.

I culminated that phase of hackery by writing a routine that would
fill memory with a copy of the Add Immediate instruction that would
decrement the program counter by 8 (twice the length of the instruction
itself), and top it off with a branch in low memory back to the end
of memory. When run, this program would loop through all of memory -
backwards.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415659 is a reply to message #415616] Wed, 27 July 2022 14:10 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-26, Peter Flass <peter_flass@yahoo.com> wrote:

> John Levine <johnl@taugh.com> wrote:
>
>> According to 25B.Z959 <25B.Z959@nada.net>:
>>
>>> Even my ASM ... every line has a comment, an ongoing
>>> narrative of what's happening and why. Based on that
>>> you could translate it into a dozen higher-level
>>> languages.
>>
>> i += 2; // Add 1 to i.
>
> For some values of one ;-)

I've heard it as "for sufficiently large values of 1".

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415660 is a reply to message #415649] Wed, 27 July 2022 14:10 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-27, Scott Lurndal <scott@slp53.sl.home> wrote:

> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> On 7/26/22 3:38 PM, John Levine wrote:
>>
>>> According to 25B.Z959 <25B.Z959@nada.net>:
>>>
>>>> Even my ASM ... every line has a comment, an ongoing
>>>> narrative of what's happening and why. Based on that
>>>> you could translate it into a dozen higher-level
>>>> languages.
>>>
>>> i += 2; // Add 1 to i.
>>
>> Um ... that'd add TWO to i .......
>
> Um, the point was that over time the comments often
> no longer reflect the code, as the code gets updated
> and the programmer doesn't update the comment. Granted
> it's more likely to occur when the comment -isn't- on the
> same line as the code to which the comment applies.

Misleading comments are worse than no comments at all.
My advice to people who don't want to maintain comments is
to delete them entirely. (The comments, that is, not the
recalcitrant programmers - although this is one of those
cases where the gene pool could use a little chlorine.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415661 is a reply to message #415635] Wed, 27 July 2022 14:10 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-07-27, 25B.Z959 <25B.Z959@nada.net> wrote:

> On 7/26/22 4:53 PM, Vir Campestris wrote:
>
>> The useful comments don't say _what_ you're doing, they say _why_.
>
> 'Zactly ... it needs to be a 'narrative' - both WHAT and WHY.
> Doesn't matter if it's ASM or COBOL or FORTRAN or Python. If
> you or anybody would EVER need to go back and tweak the pgm
> it really NEEDS serious commenting. Alas it's kinda RARE to
> see this ..... the old "Well *I* know what it's all about NOW"
> attitude. Wait a couple years until the boss decides your form
> needs some new data fields or entry box #7 moved 10 spaces to
> the right 'cause it would 'look nicer' .... :-)

Don't laugh. Once upon a time, every shop in Canada that ran payroll
had to modify their programs that generated T4 forms (Statement of
Remuneration Paid) because someone in Ottawa decided to move one
box one space to the right.

The hairiest change I was involved in, though, was when the government
decided to turn the form upside down, i.e. put the row of numbers
across the top rather than the bottom. (Or maybe it was the other way
around, I can't remember.) I was maintaining the program in a shop
whose card-based machine's memory was so small that it didn't have
room to store all of an employee's information. It would read the
card containing the employee's name, print it out, then work its
way through the cards with the employee's address, city, etc.
Finally it would read the card with the actual numbers and
print them. The card deck was sorted by employee number and
a sequence code that ensured that name, address, and statistics
were in the proper order. Not only did I have to overhaul the
program's logic to handle the different sequence, the entire
card deck had to be re-punched (and re-sorted) with the modified
sequence code.

There has to be a better way to fight unemployment...

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: COBOL and tricks [message #415664 is a reply to message #415639] Wed, 27 July 2022 15:49 Go to previous messageGo to previous message
Anonymous
Karma:
Originally posted by: drb

> There's an old joke about a college prof (and a friend
> of mine had one JUST like it) where the prof slams down
> five lines of ultra-dense next-level math on the blackboard
> then kinda half turns to the class and says "So, obviously ..."

The flip side one is "and now, by simple arithmetic... oops".

DE
Pages (21): [ «    1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: R.I.P. Terry Davis - TempleOS and Holy C
Next Topic: Satan's Digital Butthole - R.I.P. Mr. P.J. O'Rourke
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 09:02:49 EDT 2024

Total time taken to generate the page: 0.09217 seconds