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).

"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.

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

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.

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.

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.

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.

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.

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.

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.

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.

> 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

On Tue, 26 Jul 2022 22:57:21 -0400
"25B.Z959" <25B.Z959@nada.net> wrote:

> 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 ..."

There's a (possibly apocryphal) story of a professor who upon being
challenged on one such obviously, paused to think for a bit then left the
room for some time before returning to declare that yes it was obvious.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

Dan Espen <dan1espen@gmail.com> wrote:
> 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.
>
>

I stopped using COBOL before then.

--
Pete

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.
> Does the C language enforce that memory at (page) address 0 is
> unaddressable?
>
>

It’s the hardware access bits and/or memory map. Virtual address 0 can be
anything the system wants it to be.

--
Pete

On 7/25/22 7:37 AM, Johnny Billquist wrote:
> 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 lack of length checking depends on the function. Nothing prevents
> you from using strncpy in C. Or write your own, with whatever
> characteristic you want. It will actually be pretty efficient.
> Comparable to the provided functions.
>
> > I have used both languages quite a bit, perhaps COBOL more, years
> ago, but
> > neither is my preferred language, so I have no dog in this fight.
> > …
> Seems like your C is both rusty and bad.
>
> >>    Mostly I like "terse" languages - less typing and lots
> >>    of room left over for comments at the ends of the lines.
> >
> > Sounds like assembler ;-)
> >
> > It’s too easy to write tricky code with side-effects in C. COBOL
> might not
> > be as self-documenting as advertised, but the operation of each
> statement
> > is pretty obvious and easily understood.
> What kind of side effects are we talking about? The operation of each
> statement in C is very obvious and easy to understand.
> Most people get into trouble because of memory handling. Not the
> language semantics.
> But that is where you get to the point where things gets even harder to
> even do in COBOL. And if you manage to do it, it won't be easily
> understood.

Consider "print x" ... those of us that go back some years
will acutely recognize how "print x" stands atop a veritable
Everest of subroutines, device abstractors, drivers for
display controllers .........

CPUs don't *have* a "print x".

Long long back I was writing something akin to 'Notepad' for
the first IBM-PCs (this was in the days of 'edlin' and the
"A>" prompt) with MASM. Now I had (and still have) the
IBM-PC TECHNICAL REFERENCE MANUAL and it was only there where
all the ROM-BIOS calls were described in detail. You could
"print x" ... but it took some BIOS calls to actually push it
out to the screen. OR - you could poke values directly into
the display buffer ... preferably during the blanking inverval.

Depending on WHAT you need to do, COBOL can be great, or
just awful, perhaps even unusable. Whatever it is you CAN
do it in 'C' ... but it might take so MUCH 'C' that you
never actually dare begin.

In short, no 'perfect' all-purpose solutions. Be a bit
versatile or you'll never get it done.

All the talk about COBOL ... I've installed the OpenCOBOL IDE
and am gonna re-learn the language to some degree :-)

On 7/26/22 4:48 AM, Johnny Billquist 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.

True. The damned hardware dictates the details.

Oh "strncpy(st,st,5)" ... where your destination
is the also the source ... may not work as expected
on all compilers. This has lately popped up in GCC
where it wasn't an issue before. It'll probably
go away with the next sub-sub version. Meanwhile I
had to write a 'MYstrncpy()'. Probably gets even more
interesting if yer after a "strsegcpy(*src, *dest, start,end)"
where 'start' is an offset to *src ... ie you're copying up to
n chars starting from somewhere in the middle of the string
and building the result from *src onwards.

So - the hardware can dictate the ASM, but micro-revisions
in the compiler can make for unexpected results as well.
I wonder how many programs break because of such things ?

> 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.

Well, sometimes a function works better, sometimes
a statement, sometimes a sub ..... if yer language
can easily be bent to doing all three ways then
you're golden. 'C' is more like that than COBOL, but
ya gotta add more comments :-)

On 7/26/22 7:44 AM, Dan Espen 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.

But then it has to deal with packed decimals ... :-)

'Efficient' is kind of relative - is it fewer ASM bytes
or fewer ultimate CPU cycles ?

Little microcontrollers can be educational in this respect.
Almost no RAM, or EEPROM, or clock speed. What's "efficient"
can change in just a few lines.

"25B.Z959" <25B.Z959@nada.net> writes:

> On 7/26/22 7:44 AM, Dan Espen 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.
>
>
> But then it has to deal with packed decimals ... :-)
>
> 'Efficient' is kind of relative - is it fewer ASM bytes
> or fewer ultimate CPU cycles ?
>
> Little microcontrollers can be educational in this respect.
> Almost no RAM, or EEPROM, or clock speed. What's "efficient"
> can change in just a few lines.

CPU cycles. Converting decimal/binary is always slow.

--
Dan Espen

"25B.Z959" <25B.Z959@nada.net> writes:
>On 7/25/22 7:37 AM, Johnny Billquist wrote:

> Consider "print x" ... those of us that go back some years
> will acutely recognize how "print x" stands atop a veritable
> Everest of subroutines, device abstractors, drivers for
> display controllers .........
>
> CPUs don't *have* a "print x".

Arguable. e.g. the intel OUT instruction can easily print 'x',
and REP OUT can print an entire string.

>
> Long long back I was writing something akin to 'Notepad' for
> the first IBM-PCs (this was in the days of 'edlin' and the
> "A>" prompt) with MASM.

That would be quite late to the game.

On 28/07/2022 12:01, Dan Espen wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>
>>
>> But then it has to deal with packed decimals ... :-)
>>
>> 'Efficient' is kind of relative - is it fewer ASM bytes
>> or fewer ultimate CPU cycles ?
>>
Depends. Sometimes it was lack of EPROM space
Sometimes it was lack of CPU Hz.
What isn't efficient is low source code byte count achieved by removing
the comments

--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

On Thu, 28 Jul 2022 15:10:25 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> What isn't efficient is low source code byte count achieved by removing
> the comments

It is in interpreted code!

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/25/22 7:37 AM, Johnny Billquist wrote:
>> 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 lack of length checking depends on the function. Nothing prevents
>> you from using strncpy in C. Or write your own, with whatever
>> characteristic you want. It will actually be pretty efficient.
>> Comparable to the provided functions.
>>
>>> I have used both languages quite a bit, perhaps COBOL more, years
>> ago, but
>>> neither is my preferred language, so I have no dog in this fight.
>>> …
>> Seems like your C is both rusty and bad.
>>
>>>>     Mostly I like "terse" languages - less typing and lots
>>>>     of room left over for comments at the ends of the lines.
>>>
>>> Sounds like assembler ;-)
>>>
>>> It’s too easy to write tricky code with side-effects in C. COBOL
>> might not
>>> be as self-documenting as advertised, but the operation of each
>> statement
>>> is pretty obvious and easily understood.
>> What kind of side effects are we talking about? The operation of each
>> statement in C is very obvious and easy to understand.
>> Most people get into trouble because of memory handling. Not the
>> language semantics.
>> But that is where you get to the point where things gets even harder to
>> even do in COBOL. And if you manage to do it, it won't be easily
>> understood.
>
> Consider "print x" ... those of us that go back some years
> will acutely recognize how "print x" stands atop a veritable
> Everest of subroutines, device abstractors, drivers for
> display controllers .........
>
> CPUs don't *have* a "print x".

I think the 1401 did. It had instructions for “read a card”, “print a
line”, etc.

>
> Long long back I was writing something akin to 'Notepad' for
> the first IBM-PCs (this was in the days of 'edlin' and the
> "A>" prompt) with MASM. Now I had (and still have) the
> IBM-PC TECHNICAL REFERENCE MANUAL and it was only there where
> all the ROM-BIOS calls were described in detail. You could
> "print x" ... but it took some BIOS calls to actually push it
> out to the screen. OR - you could poke values directly into
> the display buffer ... preferably during the blanking inverval.
>
> Depending on WHAT you need to do, COBOL can be great, or
> just awful, perhaps even unusable. Whatever it is you CAN
> do it in 'C' ... but it might take so MUCH 'C' that you
> never actually dare begin.
>
> In short, no 'perfect' all-purpose solutions. Be a bit
> versatile or you'll never get it done.
>
> All the talk about COBOL ... I've installed the OpenCOBOL IDE
> and am gonna re-learn the language to some degree :-)
>

--
Pete

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 28/07/2022 12:01, Dan Espen wrote:
>> "25B.Z959" <25B.Z959@nada.net> writes:
>>
>>
>>>
>>> But then it has to deal with packed decimals ... :-)
>>>
>>> 'Efficient' is kind of relative - is it fewer ASM bytes
>>> or fewer ultimate CPU cycles ?
>>>
> Depends. Sometimes it was lack of EPROM space
> Sometimes it was lack of CPU Hz.
> What isn't efficient is low source code byte count achieved by removing
> the comments
>

Unless your source is on paper tape.

--
Pete

Peter Flass <peter_flass@yahoo.com> writes:
>25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/25/22 7:37 AM, Johnny Billquist wrote:

>>> But that is where you get to the point where things gets even harder to
>>> even do in COBOL. And if you manage to do it, it won't be easily
>>> understood.
>>
>> Consider "print x" ... those of us that go back some years
>> will acutely recognize how "print x" stands atop a veritable
>> Everest of subroutines, device abstractors, drivers for
>> display controllers .........
>>
>> CPUs don't *have* a "print x".
>
>I think the 1401 did. It had instructions for “read a card”, “print a
>line”, etc.

The PDP-8 has instructions to read a card, to read and
write from a teletype or paper tape punch et alia.

Many computers of that era have similar capabilities.