| Re: COBOL and tricks [message #415665 is a reply to message #415639] |
Wed, 27 July 2022 16:28   |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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/
|
|
|
|
| Re: COBOL and tricks [message #415670 is a reply to message #415630] |
Wed, 27 July 2022 18:19 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415671 is a reply to message #415643] |
Wed, 27 July 2022 18:19 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415674 is a reply to message #415517] |
Wed, 27 July 2022 21:37 |
|
|
Originally posted by: 25B.Z959
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 :-)
|
|
|
|
| Re: COBOL and tricks [message #415676 is a reply to message #415568] |
Wed, 27 July 2022 22:48 |
|
|
Originally posted by: 25B.Z959
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 :-)
|
|
|
|
| Re: COBOL and tricks [message #415677 is a reply to message #415570] |
Wed, 27 July 2022 23:00 |
|
|
Originally posted by: 25B.Z959
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.
|
|
|
|
| Re: COBOL and tricks [message #415685 is a reply to message #415677] |
Thu, 28 July 2022 07:01 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"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
|
|
|
|
| Re: COBOL and tricks [message #415686 is a reply to message #415674] |
Thu, 28 July 2022 09:02 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"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.
|
|
|
|
| Re: COBOL and tricks [message #415687 is a reply to message #415685] |
Thu, 28 July 2022 10:10 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
|
|
| Re: COBOL and tricks [message #415698 is a reply to message #415674] |
Thu, 28 July 2022 15:13 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415699 is a reply to message #415687] |
Thu, 28 July 2022 15:13 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: COBOL and tricks [message #415700 is a reply to message #415698] |
Thu, 28 July 2022 15:49 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: COBOL and tricks [message #415702 is a reply to message #415698] |
Thu, 28 July 2022 16:35 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> I think the 1401 did. It had instructions for “read a card”, “print a
> line”, etc.
Yes. a "1" with a word mark under it would read a card into locations
1-80. A "2" with a word mark under it would print locations 201-332.
A "3" with a word mark would do both, something I never saw worked into
a program.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415705 is a reply to message #415702] |
Thu, 28 July 2022 20:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> I think the 1401 did. It had instructions for “read a card”, “print a
>> line”, etc.
>
> Yes. a "1" with a word mark under it would read a card into locations
> 1-80. A "2" with a word mark under it would print locations 201-332.
>
> A "3" with a word mark would do both, something I never saw worked into
> a program.
>
>
you’d have to overlap - read a card, process it, and create the output
line. Then with one instruction you could print the output line and read
the next card.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415707 is a reply to message #415686] |
Thu, 28 July 2022 23:40 |
|
|
Originally posted by: 25B.Z959
On 7/28/22 9:02 AM, Scott Lurndal wrote:
> "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.
ONLY if it has something to print TO ... and THAT
requires a whole chain of device drivers/devices.
Stuff doesn't just appear by magic on those screens
or printers and such. The CPU has no idea what
it's OUT/REP OUTing TO. It just sends a stream of
binary. What does it MEAN, to WHAT ???
Best bet for "universal output" is to work a standard
serial port UART. You can make a "dumb" (still a lot
of firmware in there) terminal do something with that.
>> 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.
After UNIVAC for sure :-)
Closer to the dawn of PCs - Commodore/Atari/Tandy/Apple/etc.
Loved those things. No more Data Center overlords or big
stacks of punch cards ......
Still have a VIC-20 in The Heap somewhere - and a ZX-81 :-)
However it WAS a fruitful era, for IT types anyhow, because
lots and lots of software/routines that had been written for
diverse mainframe/mini systems needed to be ported over to
the new, IBM-PC, standard that had emerged. Stuff in COBOL,
FORTRAN, APL, Algol-68, PDP-11 assembler, early 'C' and such.
Some of it was intended for CP/M, some for VMS, System 360/370,
pick a company and it had its own proprietary OS and the
software was writ to correspond to those systems.
I fell in with an outfit that was kind of a refuge for
university sci types that got sick of trying to live
from grant to grant and doubly sick of academic politics.
They could continue their favorite things and get a steady
paycheck and mellow bosses instead. Their old software/data
had to be ported/improved, new software/hardware/methods for
new projects had to be made. I was young and had lots of
energy. Interesting and FUN ! Pay wasn't too bad either -
most outfits didn't really have their own IT person, but
were stuck contracting out to 3rd parties and TRYING to
make them understand was was needed/desired.
Being able to do a little "programming" with solder was
an asset too. Once upon a time what you needed probably
wasn't on a shelf anywhere, you had to MAKE it.
Can't complain. All very interesting. The New Thing
Of The Week.
|
|
|
|
| Re: COBOL and tricks [message #415708 is a reply to message #415698] |
Thu, 28 July 2022 23:43 |
|
|
Originally posted by: 25B.Z959
On 7/28/22 3:13 PM, Peter Flass wrote:
> 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.
As I said to another ... just sending a binary stream out
of a pin is NOT "printing". There's a LOT between that
and actual human-readable data display.
|
|
|
|
| Re: COBOL and tricks [message #415709 is a reply to message #415702] |
Fri, 29 July 2022 00:00 |
|
|
Originally posted by: 25B.Z959
On 7/28/22 4:35 PM, Dan Espen wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> I think the 1401 did. It had instructions for “read a card”, “print a
>> line”, etc.
>
> Yes. a "1" with a word mark under it would read a card into locations
> 1-80. A "2" with a word mark under it would print locations 201-332.
>
> A "3" with a word mark would do both, something I never saw worked into
> a program.
With a LOT of software/firmware/hardware involved in-between
that instruction and the actual human-readable output ....
"High-level" instructions HIDE the underlying realities - but
those realities are STILL there. SOMEBODY has to write them.
Some years ago some guy was talking about how "easy" it was to
append to a Python list. SO ... I wrote him the 'C' equivalent -
more readable than the actual 'C' underlying Python - and said
"THAT'S what's ACTUALLY going on". I don't think he really
grasped .... but MAYBE, sometime, he'll actually study it .....
Maybe I'll re-write it in ASM and mail it to him - just for
the torture value :-)
|
|
|
|
| Re: COBOL and tricks [message #415710 is a reply to message #415705] |
Fri, 29 July 2022 00:23 |
|
|
Originally posted by: 25B.Z959
On 7/28/22 8:52 PM, Peter Flass wrote:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> I think the 1401 did. It had instructions for “read a card”, “print a
>>> line”, etc.
>>
>> Yes. a "1" with a word mark under it would read a card into locations
>> 1-80. A "2" with a word mark under it would print locations 201-332.
>>
>> A "3" with a word mark would do both, something I never saw worked into
>> a program.
>>
>>
>
> you’d have to overlap - read a card, process it, and create the output
> line. Then with one instruction you could print the output line and read
> the next card
But that's NOT how it works ... that's the high-level ABSTRACTION.
The CPU doesn't know what cards are, doesn't know what a printer
or disk or screen display is.
Few and fewer these days GET that ... they're USED to the
high-level languages. How it works is MAGIC - but somebody
somewhere had to WRITE all that Magic. (Bill Gates was
heavily involved back in the day - ever consider what
GOES into
"
10 X=5
20 PRINT X
"
???)
Consider something as boring as 'malloc()' - you have to
abstract your memory space, MANAGE it, there are tables
and such involved, lists of lists ......... and SOMEBODY
has to maintain/improve/port all that.
|
|
|
|
| Re: COBOL and tricks [message #415713 is a reply to message #415710] |
Fri, 29 July 2022 05:15 |
cb
Messages: 300
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
In article <zpKdnT0KSM59_X7_nZ2dnUU7-b_NnZ2d@earthlink.com>,
25B.Z959 <25B.Z959@nada.net> wrote:
> But that's NOT how it works
Actually sometimes it still is.
> ... that's the high-level ABSTRACTION.
.... and sometimes it's also the actual implementation.
While this is on a character-basis rather than a card-one, it still
illustrates the principle.
SMIL ("Siffer-Mkasinen I Lund", a first-generation computer in Lund,
Sweden) literally has specific instructions that type a character on the
commected typewriter.
The typewriter was not a separate peripheral - it was an integral part of
the computer. And the CPU knew about it - the CPU was designed to know
about it.
See https://www.smilemu.org/Manual.html for the SMIL emulator manual,
which also includes a description of the computers instruction set
(and you can of course download the emulator and run it).
// Christian
|
|
|
|
| Re: COBOL and tricks [message #415718 is a reply to message #415696] |
Fri, 29 July 2022 08:02 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 28/07/2022 18:11, Ahem A Rivet's Shot wrote:
> 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!
>
I think we were in this instance talking about assembler code.
--
Climate Change: Socialism wearing a lab coat.
|
|
|
|
| Re: COBOL and tricks [message #415719 is a reply to message #415699] |
Fri, 29 July 2022 08:03 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 28/07/2022 20:13, Peter Flass wrote:
> 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.
>
It is still going to end up as machine code long before you run it
--
Climate Change: Socialism wearing a lab coat.
|
|
|
|
| Re: COBOL and tricks [message #415720 is a reply to message #415705] |
Fri, 29 July 2022 08:09 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> I think the 1401 did. It had instructions for “read a card”, “print a
>>> line”, etc.
>>
>> Yes. a "1" with a word mark under it would read a card into locations
>> 1-80. A "2" with a word mark under it would print locations 201-332.
>>
>> A "3" with a word mark would do both, something I never saw worked into
>> a program.
>
> you’d have to overlap - read a card, process it, and create the output
> line. Then with one instruction you could print the output line and read
> the next card.
Yep, just never saw anyone put in the complicated logic to do it.
Of course if you're reading cards to print a report you're going to have
to account for the logic to print headings, totals...
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415721 is a reply to message #415710] |
Fri, 29 July 2022 08:13 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/28/22 8:52 PM, Peter Flass wrote:
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> I think the 1401 did. It had instructions for “read a card”, “print a
>>>> line”, etc.
>>>
>>> Yes. a "1" with a word mark under it would read a card into locations
>>> 1-80. A "2" with a word mark under it would print locations 201-332.
>>>
>>> A "3" with a word mark would do both, something I never saw worked into
>>> a program.
>>>
>>>
>> you’d have to overlap - read a card, process it, and create the
>> output
>> line. Then with one instruction you could print the output line and read
>> the next card
>
> But that's NOT how it works ... that's the high-level ABSTRACTION.
I have no idea what you are trying to say.
A high level abstraction to read a card?
You issued the read command, the system read the card.
If you are talking about things like engaging the clutch on the card
reader and other stuff that went on, that's entirely irrelevant.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415723 is a reply to message #415707] |
Fri, 29 July 2022 11:54 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/28/22 9:02 AM, Scott Lurndal wrote:
>> "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.
>
>
> ONLY if it has something to print TO ... and THAT
> requires a whole chain of device drivers/devices.
No, it does not. Please do some reading and understand
what the IN and OUT instructions actually do.
|
|
|
|
| Re: ancient I/O, was COBOL and tricks [message #415728 is a reply to message #415700] |
Fri, 29 July 2022 14:37 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
It appears that Scott Lurndal <slp53@pacbell.net> said:
>> I think the 1401 did. It had instructions for “read a card”, “print a
>> line”, etc.
As did the 360/20. If you turned off the "time sharing" switch
it would wait for the operation to be done so you didn't have
to do a busy loop, but then you didn't get to do anything else
in the meantime.
> The PDP-8 has instructions to read a card, to read and
> write from a teletype or paper tape punch et alia.
Sort of. I never saw a PDP-8 with a card reader but according
to my 1972 Small Computer Handbook, it had instructions like
RCRF for skip on data ready, RCRB to read a column as 12 bits,
RCRA to read a column as six bit BCD, RCRC to read a column
as 8 bits which was almost but not quite EBCDIC, RCSE to skip
if the reader is ready, RCSD to skip on card done, and so forth.
Reading a card took a lot more than one instruction.
For the console TTY there was KSF to skip if a character was
ready, KRB to read the character into the AC, KIE to turn
the keyboard interrupt on or off, TSF to skip if it was
ready for output, TLS to send a character, TIE to turn
the interrupt on or off, and so forth.
But if you had a lot of TTYs, you'd get the 680 which interrupted on
each bit time (110 times/sec for ttys, 300 times/sec for 300 baud
devices) and scanned the characters and start bits in or out one bit
at a time.
One of the amazing things about TSS/8 is that it could run a bunch of
TTY lines on a 680 and still have enough time left to run a
time-sharing system which gave each user something close to a virtual
4K PDP-8.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different languages, was COBOL and tricks [message #415729 is a reply to message #415709] |
Fri, 29 July 2022 14:55 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to 25B.Z959 <25B.Z959@nada.net>:
> Some years ago some guy was talking about how "easy" it was to
> append to a Python list. SO ... I wrote him the 'C' equivalent -
> more readable than the actual 'C' underlying Python - and said
> "THAT'S what's ACTUALLY going on". I don't think he really
> grasped .... but MAYBE, sometime, he'll actually study it .....
I don't understand what point you're trying to make. I've written
plenty of list management code in C and I am quite happy to leave
the details to the python interpreter. Yeah, someone had to write
the python interpreter, but someone had to write the C compiler, too.
> Maybe I'll re-write it in ASM and mail it to him - just for
> the torture value :-)
Now I'm wondering how you expect your ASM source to turn into
machine code.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: COBOL and tricks [message #415739 is a reply to message #415709] |
Fri, 29 July 2022 17:41 |
|
|
Originally posted by: drb
> With a LOT of software/firmware/hardware involved in-between
> that instruction and the actual human-readable output ....
What people have been patiently trying to explain to you is that on many
older machines, there was only hardware in between. These i/o
instructions that have been mentioned are NOT high level instructions.
They cause the CPU to put a bit pattern out a given set of signal lines.
Many of the CPUs in that era weren't even microcoded. The original
PDP-8 certainly wasn't. And most of the i/o devices weren't intelligent
either. Sending a character to a console teletype is a question of
sending a sequence of electrical pulses down a wire. The teletype
itself wasn't even electronic. It was purely electromechanical. Many
of the earlier card and paper tape devices were not at all intelligent,
but made up purely of some simple logic circuits.
De
|
|
|
|
| Re: COBOL and tricks [message #415741 is a reply to message #415707] |
Fri, 29 July 2022 18:02 |
|
|
Originally posted by: drb
> Best bet for "universal output" is to work a standard
> serial port UART. You can make a "dumb" (still a lot
> of firmware in there) terminal do something with that.
The earliest ones had no firmware in there at all. No CPU either. Pure
logic-gate marble machines. No UARTs either, in some of them, since the
concept wasn't available in IC form until 1971 or so.
De
|
|
|
|
| Re: COBOL and tricks [message #415743 is a reply to message #415708] |
Fri, 29 July 2022 18:23 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/28/22 3:13 PM, Peter Flass wrote:
>> 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.
>
> As I said to another ... just sending a binary stream out
> of a pin is NOT "printing". There's a LOT between that
> and actual human-readable data display.
>
I think it would have been all hardware on the 1401 - not even firmware,
which wasn’t invented yet.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415744 is a reply to message #415719] |
Fri, 29 July 2022 18:23 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 28/07/2022 20:13, Peter Flass wrote:
>> 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.
>>
> It is still going to end up as machine code long before you run it
>
>
If you punch your code on cards, you get one instruction per card. The
other sixty or so characters will be there whether they’re blanks or a
comment, so you might as well comment. If you use paper tape, comments will
balloon the size of your source to several times it’s size, and you have to
read in all that tape to compile. I think early tapes used card-images,
blocked or unblocked, so, again, comments were “free.”
--
Pete
|
|
|
|
| Re: old firms, was COBOL and tricks [message #415746 is a reply to message #415743] |
Fri, 29 July 2022 18:58 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
> I think it would have been all hardware on the 1401 - not even firmware,
> which wasn’t invented yet.
Maurice Wilkes invented sequenced microcode in 1951 and the Whirlwind
had a diode control store in 1947.
IBM did some internal experiments with microcode in 1957 but the
low end S/360s were their first microprogrammed products. The 1401
was indeed hardwired.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: COBOL and tricks [message #415753 is a reply to message #415721] |
Fri, 29 July 2022 23:57 |
|
|
Originally posted by: 25B.Z959
On 7/29/22 8:13 AM, Dan Espen wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> On 7/28/22 8:52 PM, Peter Flass wrote:
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>>
>>>> > I think the 1401 did. It had instructions for “read a card”, “print a
>>>> > line”, etc.
>>>>
>>>> Yes. a "1" with a word mark under it would read a card into locations
>>>> 1-80. A "2" with a word mark under it would print locations 201-332.
>>>>
>>>> A "3" with a word mark would do both, something I never saw worked into
>>>> a program.
>>>>
>>>>
>>> you’d have to overlap - read a card, process it, and create the
>>> output
>>> line. Then with one instruction you could print the output line and read
>>> the next card
>>
>> But that's NOT how it works ... that's the high-level ABSTRACTION.
>
> I have no idea what you are trying to say.
>
> A high level abstraction to read a card?
Hell YES !!!
Do you think the CPU knows what a "card" or "card
reader" is ?
The CPU, given the instruction, would send a byte-stream.
However you had to have another "computer" attached that
knew exactly what to DO with it - ie the printer or card
reader. The card reader then sends BACK stuff, which
requires more instructions to even absorb at the most
basic level.
Merely "offloading" the computing task doesn't make
"read a card" a low-level instruction.
If you VERY closely design your peripherials in concert
with your CPU you CAN cut some corners though. Ultra-
proprietary "systems" were the norm until the late '60s.
> You issued the read command, the system read the card.
> If you are talking about things like engaging the clutch on the card
> reader and other stuff that went on, that's entirely irrelevant.
>
No - NOT irrelevant at all.
We seem to have different viewpoints on all this. I see
it from lowest-level up whereas you seem to see it from
highest-level down - and not very far down. It's usually
the younger crowd that just accepts the "magic" and never
pries underneath. Send a mail/text/video - why, you just
click the "Send" button ...... no need to think about
it further ....
But SOMEBODY has to think about it.
|
|
|
|
| Re: different languages, was COBOL and tricks [message #415754 is a reply to message #415729] |
Sat, 30 July 2022 00:53 |
|
|
Originally posted by: 25B.Z959
On 7/29/22 2:55 PM, John Levine wrote:
> According to 25B.Z959 <25B.Z959@nada.net>:
>> Some years ago some guy was talking about how "easy" it was to
>> append to a Python list. SO ... I wrote him the 'C' equivalent -
>> more readable than the actual 'C' underlying Python - and said
>> "THAT'S what's ACTUALLY going on". I don't think he really
>> grasped .... but MAYBE, sometime, he'll actually study it .....
>
> I don't understand what point you're trying to make. I've written
> plenty of list management code in C and I am quite happy to leave
> the details to the python interpreter. Yeah, someone had to write
> the python interpreter, but someone had to write the C compiler, too.
There's no HARM in leaving it to the high-level language - that's
what they're for, a shorthand.
But to imagine there's nothing but "magic" beneath those
high-level instructions is an insult to those who put in
the HARD work.
And once in a while they got it a little wrong ... how to
fix that, or at least get around it ? :-)
>> Maybe I'll re-write it in ASM and mail it to him - just for
>> the torture value :-)
>
> Now I'm wondering how you expect your ASM source to turn into
> machine code.
Via a macro-assembler preferably, though you CAN do it
with a non-MASM. I knew a weird guy who made money
making video-game cartridges for PET/C64 computers
and did it all in 6502 BINARY-code ovia a MLMonitor-
said it "gave him a buzz". He was one of those guys SO
bright he was nuts.
Wasn't THAT long ago you programmed your Altair by
setting physical switches to the correct binary codes,
pressed the enter button, then manually advanced the
address counter ........
One of my big regrets was never learning how to
actually design a CPU chip - HOW the logic grabs
those bytes, decodes them, sets things in motion.
To me that's still kinda "magic" - but at least
I acutely understand that there's a whole level
of reasoning and design underlying. If I could
build - and UNDERSTAND - even a Z80 then I'd be
happier.
I did run into an article a few years back about
somebody who built a Z80 from DISCRETE COMPONENTS.
Covered three big walls in his home. That's really
next-level obsession .......
Now creating Python-style lists isn't THAT difficult.
Linked lists with optional links to lower-level linked
lists and so forth - trunk, branches, littler branches
and eventually leaves. It's not hyper-efficient with
memory but it's logical and easily scalable and you
can re-use most of the functions. Turns into quite a
dense bush though if your list contains sub-lists which
contain sub-lists. This is the "magic" underlying
L1.append(['a','b','c']) or better an insert. SEEMS so
EASY in Python ......... :-)
Hmmm ... now if the leaves kinda KNEW some stuff
about what's in the other twigs/branches .....
'self-aware lists' ... maybe self-reorganize to
match the 'common use' it sees .... hmm ... that's
where the fun stuff starts .........
But these days everyone's into faux 'neural networks'.
MAYBE, well, Nature had to make do with the materials
at hand, but WE have a bigger library ..... :-)
Anyhow .........
|
|
|
|
| Re: COBOL and tricks [message #415755 is a reply to message #415739] |
Sat, 30 July 2022 01:03 |
|
|
Originally posted by: 25B.Z959
On 7/29/22 5:41 PM, Dennis Boone wrote:
>> With a LOT of software/firmware/hardware involved in-between
>> that instruction and the actual human-readable output ....
>
> What people have been patiently trying to explain to you is that on many
> older machines, there was only hardware in between.
"Hardware" just means "programmed in Solder".
> These i/o
> instructions that have been mentioned are NOT high level instructions.
> They cause the CPU to put a bit pattern out a given set of signal lines.
> Many of the CPUs in that era weren't even microcoded. The original
> PDP-8 certainly wasn't. And most of the i/o devices weren't intelligent
> either. Sending a character to a console teletype is a question of
> sending a sequence of electrical pulses down a wire. The teletype
> itself wasn't even electronic. It was purely electromechanical. Many
> of the earlier card and paper tape devices were not at all intelligent,
> but made up purely of some simple logic circuits.
In the days of ultra-proprietary systems you COULD take
some shortcuts. Your UltraComp CPU expected an UltraComp
card-reader, an UltraComp TTY, an UltraComp tape drive ...
But that began to change very quickly in the 70s. Then
we saw "device drivers" - complicated little programs
and tables unto themselves - the maturation of 'device
abstraction'.
|
|
|
|
| Re: COBOL and tricks [message #415756 is a reply to message #415743] |
Sat, 30 July 2022 01:04 |
|
|
Originally posted by: 25B.Z959
On 7/29/22 6:23 PM, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/28/22 3:13 PM, Peter Flass wrote:
>>> 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.
>>
>> As I said to another ... just sending a binary stream out
>> of a pin is NOT "printing". There's a LOT between that
>> and actual human-readable data display.
>>
>
> I think it would have been all hardware on the 1401 - not even firmware,
> which wasn’t invented yet.
Hardware just means "programmed in Solder" ....
|
|
|
|
| Re: COBOL and tricks [message #415757 is a reply to message #415753] |
Sat, 30 July 2022 08:13 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/29/22 8:13 AM, Dan Espen wrote:
>> "25B.Z959" <25B.Z959@nada.net> writes:
>>
>>> On 7/28/22 8:52 PM, Peter Flass wrote:
>>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> > Peter Flass <peter_flass@yahoo.com> writes:
>>>> >
>>>> >> I think the 1401 did. It had instructions for “read a card”, “print a
>>>> >> line”, etc.
>>>> >
>>>> > Yes. a "1" with a word mark under it would read a card into locations
>>>> > 1-80. A "2" with a word mark under it would print locations 201-332.
>>>> >
>>>> > A "3" with a word mark would do both, something I never saw worked into
>>>> > a program.
>>>> >
>>>> >
>>>> you’d have to overlap - read a card, process it, and create the
>>>> output
>>>> line. Then with one instruction you could print the output line and read
>>>> the next card
>>>
>>> But that's NOT how it works ... that's the high-level ABSTRACTION.
>> I have no idea what you are trying to say.
>> A high level abstraction to read a card?
>
>
> Hell YES !!!
>
> Do you think the CPU knows what a "card" or "card
> reader" is ?
>
> The CPU, given the instruction, would send a byte-stream.
> However you had to have another "computer" attached that
> knew exactly what to DO with it - ie the printer or card
> reader. The card reader then sends BACK stuff, which
> requires more instructions to even absorb at the most
> basic level.
>
> Merely "offloading" the computing task doesn't make
> "read a card" a low-level instruction.
>
> If you VERY closely design your peripherials in concert
> with your CPU you CAN cut some corners though. Ultra-
> proprietary "systems" were the norm until the late '60s.
>
>
>> You issued the read command, the system read the card.
>> If you are talking about things like engaging the clutch on the card
>> reader and other stuff that went on, that's entirely irrelevant.
>>
>
> No - NOT irrelevant at all.
>
> We seem to have different viewpoints on all this. I see
> it from lowest-level up whereas you seem to see it from
> highest-level down - and not very far down. It's usually
> the younger crowd that just accepts the "magic" and never
> pries underneath. Send a mail/text/video - why, you just
> click the "Send" button ...... no need to think about
> it further ....
>
> But SOMEBODY has to think about it.
Well, I still think you are completely wrong.
The 1401 certainly did know how to read a card with only the wiring in
the CPU.
Your comments about the "younger crowd" are also without basis.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415758 is a reply to message #415755] |
Sat, 30 July 2022 08:16 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/29/22 5:41 PM, Dennis Boone wrote:
>>> With a LOT of software/firmware/hardware involved in-between
>>> that instruction and the actual human-readable output ....
>> What people have been patiently trying to explain to you is that on
>> many
>> older machines, there was only hardware in between.
>
> "Hardware" just means "programmed in Solder".
No.
Words have meaning. Programming and soldering are 2 different things.
You may want to call driving a stake into the ground programming
building a tent, but it's not.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415761 is a reply to message #415739] |
Sat, 30 July 2022 10:56 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
drb@ihatespam.msu.edu (Dennis Boone) writes:
>> With a LOT of software/firmware/hardware involved in-between
>> that instruction and the actual human-readable output ....
>
> What people have been patiently trying to explain to you is that on many
> older machines, there was only hardware in between. These i/o
> instructions that have been mentioned are NOT high level instructions.
> They cause the CPU to put a bit pattern out a given set of signal lines.
> Many of the CPUs in that era weren't even microcoded. The original
> PDP-8 certainly wasn't. And most of the i/o devices weren't intelligent
> either. Sending a character to a console teletype is a question of
> sending a sequence of electrical pulses down a wire. The teletype
> itself wasn't even electronic. It was purely electromechanical. Many
> of the earlier card and paper tape devices were not at all intelligent,
> but made up purely of some simple logic circuits.
Take the Burroughs B3500 family; to read a single card into memory
was a single instruction (well, not counting the wait for completion).
II0 /01 IOD
And at address IOD, there is an I/O descriptor
consisting of a buffer start address (A), a buffer
end address(B), and an optional "C" field.
The Descriptor
400D00 000000 000159 000000
would read a card from channel one into memory starting at address A
zero through address B 159 (80 bytes). Change the @D@ to @C@ and it
would convert the hollerith to EBCDIC instead of 6-bit BCL before
storing in memory. Use @F@ and it would read as many cards as would
fit into the supplied buffer.
The A and B address fields provide the bounds of the memory buffer
(recalling that the system addresses to the digit (nibble)).
The C address field provided the
sector number for disk I/O's and a block count for 7/9/18track tape
skip forward/backward ops.
Similarly for the printer,
420000 000000 000264 000000
would print a single line to the line printer on channel 3 from
memory starting at address zero. The 6th digit of the descriptor
encoded the channel number on the printer carriage control tape,
where was no-paper-motion, 1 was advance to head of page, then
channels 2-11 on the tape, end of page, single and double space.
Waiting for completion was a simple loop waiting for a bit to
be set in a channel specific area of low memory (a 4 digit
result descriptor that encoded completion status and error
conditions).
Hardware in production from 1966 through 2012.
|
|
|
|
| Re: COBOL and tricks [message #415762 is a reply to message #415753] |
Sat, 30 July 2022 11:04 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"25B.Z959" <25B.Z959@nada.net> writes:
> On 7/29/22 8:13 AM, Dan Espen wrote:
>> I have no idea what you are trying to say.
>>
>> A high level abstraction to read a card?
>
>
> Hell YES !!!
>
> Do you think the CPU knows what a "card" or "card
> reader" is ?
No, it doesn't care.
>
> The CPU, given the instruction, would send a byte-stream.
The CPU, given the instruction, sends a set of signals to the
I/O subsystem which reach the device controller.
> However you had to have another "computer" attached that
No, the simple logic circuits to decode and route the signals
sent from the CPU are not a "computer" using any definition of
the word.
It is logic all the way down.
|
|
|
|
Members
Search
Help
Register
Login
Home
