On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

> For instance, the 2038 problem I'm betting will be ignored until 2035.

It’s not being ignored. The Linux kernel added the option to build a 32-
bit kernel with time_t having 64 bits, and Debian has been going through a
reorg to incorporate this into its 32-bit builds (look for package names
appearing with “t64” in there somewhere).

On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

> Then, people ignore the problem until it's right there.
> For instance, the 2038 problem I'm betting will be ignored until 2035.

Oh you silly optimist... There may be articles in the tech press about the
coming disaster in 2035 but it will be 2037 before anything gets done.

I was hired in 1999 to fix Y2K problems. I liked the environment so I
stayed 25 years. I guess I'm getting old. I used to leave perfectly good
jobs because I didn't see the Next Big Project on the horizon. Always
leave them smiling though. I returned to several of the companies as a
contractor.

On 9/30/24 3:40 PM, candycanearter07 wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote at 07:43 this Monday (GMT):
>> On 9/30/24 3:21 AM, rbowman wrote:
>>> On Mon, 30 Sep 2024 06:03:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>>
>>>> Fun fact: I was reworking an old perpetual-calendar program I first
>>>> wrote back in 1980, to use Fortran 90, a few months ago. And I found a
>>>> bug in my algorithm that never showed up in any years from the 20th
>>>> century, but did manifest itself in the 21st century.
>>>
>>> Y2K rides again... I think in many cases the problem was recognized in
>>> the '70s and '80s but nobody expected the code to last decades.
>>
>> Very true - and TROUBLESOME.
>>
>> We all think in the NOW. With effort we can think
>> a FEW years ahead. But a whole new century or
>> something similar ... TOO MUCH WORK to future-
>> proof. We'll "get back to it", sometime ......
>
>
> Then, people ignore the problem until it's right there.
> For instance, the 2038 problem I'm betting will be ignored until 2035.

Yep, for SURE.

Human nature.

Alas the PROBLEM tends to be several times larger
than people THINK it will be, so ......

Oh sure, just make time() into a proper 64-bit
number ... but SO much downstream from that will
NOT be prepared to deal with the 64 bit value.
Basically EVERY subroutine that uses/manipulates
time are still set up assuming unsigned 32-bit
vars. This means MASS quantities of software that
has to be re-written/re-compiled (at the last
minute). Can't see ANY easy universal fix. Your
assumptions chart your future.

Yea, they can write a time64(), but everything
still has to re-done.

I may live until 2038, so this WILL be a huge
problem. Can I even get my pension/govt
payments ??? Insurance ??? Probably won't be
in shape to physically travel to offices of
all these entities.

Again, way back, 2038 seemed SO far away ...
don't worry about it ..........

On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:

>
> Then, people ignore the problem until it's right there.
> For instance, the 2038 problem I'm betting will be ignored until 2035.
>

Hasn't the 2038 problem already been fixed?

GNU/Linux has had 64-bit time for many years already.

--
Systemd: solving all the problems that you never knew you had.

Farley Flud <ff@linux.rocks> wrote:
>On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:
>
>> Then, people ignore the problem until it's right there.
>> For instance, the 2038 problem I'm betting will be ignored until 2035.
>
>Hasn't the 2038 problem already been fixed?
>
>GNU/Linux has had 64-bit time for many years already.

Uh huh, but meanwhile they would obviously keep 32-bit support longer
than M$ and crApple.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On 10/1/24 3:54 AM, Farley Flud wrote:
> On Mon, 30 Sep 2024 19:40:06 -0000 (UTC), candycanearter07 wrote:
>
>>
>> Then, people ignore the problem until it's right there.
>> For instance, the 2038 problem I'm betting will be ignored until 2035.
>>
>
> Hasn't the 2038 problem already been fixed?
>
> GNU/Linux has had 64-bit time for many years already.

It's not just HAVING 64/128-bit vars. Gotta look
at every function, every line. The original pgmr
likely specified 32-bit vars for a of of the
date-related stuff because, well, datetime is
always 32 bit, right ? Hey, the cdates/mdates
on FILES too ......

The swamp just gets deeper and deeper.

There are kind of the literal gazillion bits of
code in dozens of languages created from the
late 1950s on that are inside apps/systems
everywhere today that in some way deal
with, depend on, datetimes.

In the ancient days, there was an ultra-nerd
named Bill Gates who used to participate in,
often win, contests to see who could code
some useful function in the very least number
of bytes/cycles. Bill was something of a hero
figure then. However, he wrote that code using
the ASSUMPTIONS of the day. Betcha there's
still some of his old code in modern systems.

As such, only "AI" is going to be able to deal
with such volume and diversity. It will have to
be trained to detect datetime operations and
literally re-write the relevant code.

And we'd better make/train it QUICKLY.

On 9/24/24 3:04 PM, Lester Thorpe wrote:
> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>
>>
>> Me, I'd rather use 'C' ... which was a brand new
>> language when I got into computers - it was the
>> Cool New Thing on PDP-11s. However the syntax IS,
>> and especially can be MADE, a bit obscure. More
>> 'obvious', 'self-documenting' langs DO have an
>> advantage.
>>
>
> C is just shorthand for assembly, and assembly,
> i.e. machine, language is the language to which
> EVERYTHING else reduces.

Well, it was an improvement over 'B' which was
an improvement over BCPL ...

Done plenty of ASM over the years ... esp for
micro-controllers. Even wrote a basic page-
editor for DOS 1.x in ASM because I *hated*
'edlin' so much.

FORTH is even more 'ASM' than 'C', you can just
see those push/pops and underlying cpu commands
at work. The syntax is just, a little, nicer.
It was very popular for old CPUs and MCs because
it was so 'light' and interpretation saved some
annoying steps. You could reprogram/test your
mountaintop telescope over a 110-baud link without
having to climb the mountain ! That was a big
deal back then.

They recently had to patch Voyager-1 ... most of
its software is about 3kb of F77 (originally F5),
with a few 'C' bits added more recently. Likely
well LESS than a 110-baud connection these days ...

> Yes, C is just shorthand for assembly. Whenever I
> write C code I can always "see" the assembly instructions
> that lie beneath every C statement.

But the 'C' syntax and setup IS considerably easier.

> In fact, when it comes to SIMD programming, there are C
> functions known as "intrinsics" that allow direct access
> to SIMD hardware assembly instruction (e.g. SSE2, AVX).
> (These do not exist for any other language.)
>
>
> Conclusion:
>
> Those who understand the machine use C (assembly) and only
> C.
>
> All dumb-fuck idiots and retards, of which there are hordes
> in commercial (i.e. paid) programming, MUST use other "crutch"
> languages.

Now, now ... I would not brand all the new(er) people
as dumbfucks and idiots. There's still a lot of craft
involved in their apps. Me, 'C' aside, I always liked
Pascal much more. Even use a fair bit of Python these
days - saves lots of time. At least I can still kinda
see the 'C'/ASM underneath though the newbies cannot.

When "AI" kinda takes over then, yea, it's mostly gonna
be dumbfucks and idiots who can only generally describe
what sort of apps they want to the AI. They won't know
dick about computers/vars/structs/regs/records or anything.
Perhaps this is "where we were heading all along", but
IMHO a lot is gonna be lost.

On Wed, 2 Oct 2024 00:59:48 -0400, 186282@ud0s4.net wrote:

> FORTH is even more 'ASM' than 'C', you can just see those push/pops
> and underlying cpu commands at work. The syntax is just, a little,
> nicer.

FORTH -- the language that uses the programmer as a compiler. Experience
with FORTH is helpful when reading the Dragon book. (Compilers:
Principles, Techniques, and Tools)

On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:

>>
>> GNU/Linux has had 64-bit time for many years already.
>
> It's not just HAVING 64/128-bit vars. Gotta look
> at every function, every line. The original pgmr
> likely specified 32-bit vars for a of of the
> date-related stuff because, well, datetime is
> always 32 bit, right ? Hey, the cdates/mdates
> on FILES too ......
>

If the programmer follows ISO/POSIX standards then
it will all automatically become 64-bit because all
libc time/date functions are based on time_t, which
is an integer defined in the libc headers.

Some filesystem timestamps may still be 32-bit but
that shouldn't be hard to fix. If the filesytem is
in wide usage it should be fixed already.

> The swamp just gets deeper and deeper.
>
> There are kind of the literal gazillion bits of
> code in dozens of languages created from the
> late 1950s on that are inside apps/systems
> everywhere today that in some way deal
> with, depend on, datetimes.
>

Most C source code from the 1950's, or even the 1990's,
would not on run on current 64-bit systems anyway,
irrespective of date/time functions.

I have had to convert code from the early 2000's just
to make it run on my machine. The change from 32 to
64 bit processors forced many, many packages to be
rewritten.

But you are correct. Lot's of code won't make it but
for desktop GNU/Linux workstations this code is largely
irrelevant and may be irrelevant elsewhere as well.

--
Systemd: solving all the problems that you never knew you had.

On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:

>> GNU/Linux has had 64-bit time for many years already.
>
> It's not just HAVING 64/128-bit vars. Gotta look at every function,
> every line.

Or, you know, you define a type named “time_t”, which can be specified to
be 32 bits or 64 bits depending on the target architecture build, and use
that type wherever appropriate. Then you don’t have to worry about it any
more.

On 10/2/24 5:49 AM, Farley Flud wrote:
> On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:
>
>>>
>>> GNU/Linux has had 64-bit time for many years already.
>>
>> It's not just HAVING 64/128-bit vars. Gotta look
>> at every function, every line. The original pgmr
>> likely specified 32-bit vars for a of of the
>> date-related stuff because, well, datetime is
>> always 32 bit, right ? Hey, the cdates/mdates
>> on FILES too ......
>>
>
> If the programmer follows ISO/POSIX standards then
> it will all automatically become 64-bit because all
> libc time/date functions are based on time_t, which
> is an integer defined in the libc headers.

*IF* ....

But even I rarely did that. Same will go for
many/most? others. Yet their code is STILL
in there, still doing your paychecks, watching
for incoming Russian missiles ....

> Some filesystem timestamps may still be 32-bit but
> that shouldn't be hard to fix. If the filesytem is
> in wide usage it should be fixed already.
>
>
>> The swamp just gets deeper and deeper.
>>
>> There are kind of the literal gazillion bits of
>> code in dozens of languages created from the
>> late 1950s on that are inside apps/systems
>> everywhere today that in some way deal
>> with, depend on, datetimes.
>>
>
> Most C source code from the 1950's, or even the 1990's,
> would not on run on current 64-bit systems anyway,
> irrespective of date/time functions.

'C' doesn't go back to the 50s. FORTRAN does though,
but just barely.

As for 8-bit code ... nasty trick by Intel. However
it DOES work in common emulators. I've got DOS 2.x
with the old MS/IBM multi-pass 'C' and Pascal
compilers in a VM. It all works. Even CP/M-86 works
in a VM.

> I have had to convert code from the early 2000's just
> to make it run on my machine. The change from 32 to
> 64 bit processors forced many, many packages to be
> rewritten.

Therein lies a big part of The Problem - so MUCH
to check/fix/rewrite ... so few to do it and esp
so little MONEY for it.

> But you are correct. Lot's of code won't make it but
> for desktop GNU/Linux workstations this code is largely
> irrelevant and may be irrelevant elsewhere as well.

It's not just the desktops ... it's everything they
read/write to and everything they connect to.

IMHO, people/corps/govt will wait until the literal
last minute and they go into a panic and TRY to fix
everything - and often fail.

On 10/2/24 6:32 PM, Lawrence D'Oliveiro wrote:
> On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:
>
>>> GNU/Linux has had 64-bit time for many years already.
>>
>> It's not just HAVING 64/128-bit vars. Gotta look at every function,
>> every line.
>
> Or, you know, you define a type named “time_t”, which can be specified to
> be 32 bits or 64 bits depending on the target architecture build, and use
> that type wherever appropriate. Then you don’t have to worry about it any
> more.

Ummm ... don't think it's that easy.

Most of the code I've ever writ for dealing with
datetime has lots of vars in each individual
function for doing manipulations/math on datetimes.
They are not 'time_t' but generic 32-bit ints.
Simply creating a 'time_t' ain't gonna fix it.
You'd have to look, see, THINK, about each function
and judge which vars were being used for datetime
stuff, or not.

This sort of thing, and the scale/scope of the issue,
is why I say an "AI" fixer-upper is gonna be needed.

As for the subject line - 'Rust' is as OK as lots
of other languages. Just seems, well, redundant.
Too little Real Stuff gained. Stick to 'C'.

On Wed, 2 Oct 2024 22:25:27 -0400, 186282@ud0s4.net wrote:

> On 10/2/24 6:32 PM, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:
>>
>>>> GNU/Linux has had 64-bit time for many years already.
>>>
>>> It's not just HAVING 64/128-bit vars. Gotta look at every function,
>>> every line.
>>
>> Or, you know, you define a type named “time_t”, which can be specified
>> to be 32 bits or 64 bits depending on the target architecture build,
>> and use that type wherever appropriate. Then you don’t have to worry
>> about it any more.
>
> Ummm ... don't think it's that easy.

It is.

Think of the huge amount of open-source software that successfully
compiles, and runs, on Linux running under both 32-bit and 64-bit
architectures. Both big- and little-endian, even.

POSIX figured this out decades ago.

On 10/2/24 11:52 PM, Lawrence D'Oliveiro wrote:
> On Wed, 2 Oct 2024 22:25:27 -0400, 186282@ud0s4.net wrote:
>
>> On 10/2/24 6:32 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:
>>>
>>>>> GNU/Linux has had 64-bit time for many years already.
>>>>
>>>> It's not just HAVING 64/128-bit vars. Gotta look at every function,
>>>> every line.
>>>
>>> Or, you know, you define a type named “time_t”, which can be specified
>>> to be 32 bits or 64 bits depending on the target architecture build,
>>> and use that type wherever appropriate. Then you don’t have to worry
>>> about it any more.
>>
>> Ummm ... don't think it's that easy.
>
> It is.
>
> Think of the huge amount of open-source software that successfully
> compiles, and runs, on Linux running under both 32-bit and 64-bit
> architectures. Both big- and little-endian, even.
>
> POSIX figured this out decades ago.

But programmers with deadlines don't always FOLLOW
that stuff .....

186282@ud0s4.net <186283@ud0s4.net> wrote at 03:03 this Friday (GMT):
> On 10/2/24 11:52 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 2 Oct 2024 22:25:27 -0400, 186282@ud0s4.net wrote:
>>
>>> On 10/2/24 6:32 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote:
>>>>
>>>>>> GNU/Linux has had 64-bit time for many years already.
>>>>>
>>>>> It's not just HAVING 64/128-bit vars. Gotta look at every function,
>>>>> every line.
>>>>
>>>> Or, you know, you define a type named “time_t”, which can be specified
>>>> to be 32 bits or 64 bits depending on the target architecture build,
>>>> and use that type wherever appropriate. Then you don’t have to worry
>>>> about it any more.
>>>
>>> Ummm ... don't think it's that easy.
>>
>> It is.
>>
>> Think of the huge amount of open-source software that successfully
>> compiles, and runs, on Linux running under both 32-bit and 64-bit
>> architectures. Both big- and little-endian, even.
>>
>> POSIX figured this out decades ago.
>
>
> But programmers with deadlines don't always FOLLOW
> that stuff .....

Yeah, I'm also somewhat bad with following POSIX standards..
--
user <candycane> is generated from /dev/urandom

On Fri, 4 Oct 2024 18:00:03 -0000 (UTC), candycanearter07 wrote:

>
> Yeah, I'm also somewhat bad with following POSIX standards..
>

Don't worry about it.

Your code will always be totally inconsequential.

Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!

On Thu, 3 Oct 2024 23:03:05 -0400, 186282@ud0s4.net wrote:

> On 10/2/24 11:52 PM, Lawrence D'Oliveiro wrote:
>>
>> POSIX figured this out decades ago.
>
> But programmers with deadlines don't always FOLLOW that stuff .....

They do USE a lot of “that stuff”, though: most in-house projects these
days are crucially dependent on Open Source at some level.

Cy DeMillion <cyde@loozers.net> wrote:
>On Fri, 4 Oct 2024 18:00:03 -0000 (UTC), candycanearter07 wrote:
>
>> Yeah, I'm also somewhat bad with following POSIX standards..
>
>Don't worry about it.
>
>Your code will always be totally inconsequential.
>
>Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!

Shut up, fag.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On 10/4/2024 4:51 PM, Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 23:03:05 -0400, 186282@ud0s4.net wrote:
>
>> On 10/2/24 11:52 PM, Lawrence D'Oliveiro wrote:
>>>
>>> POSIX figured this out decades ago.
>>
>> But programmers with deadlines don't always FOLLOW that stuff .....
>
> They do USE a lot of “that stuff”, though: most in-house projects these
> days are crucially dependent on Open Source at some level.

Sez who?

On 10/4/2024 8:18 PM, Joel wrote:
> Lameass Larry (nym Cy DeMillion <cyde@loozers.net>) wrote:
>> On Fri, 4 Oct 2024 18:00:03 -0000 (UTC), candycanearter07 wrote:
>>
>>> Yeah, I'm also somewhat bad with following POSIX standards..
>>
>> Don't worry about it.
>>
>> Your code will always be totally inconsequential.
>>
>> Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha!
>
>
> Shut up, fag.

Feeb's projecting again, angry beyond belief because nobody will pay him
to write computer programs. So it turns out all HIS code is actually
inconsequential, hobbyist dreck.

FACTS.

On 9/24/24 3:04 PM, Lester Thorpe wrote:
> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>
>>
>> Me, I'd rather use 'C' ... which was a brand new
>> language when I got into computers - it was the
>> Cool New Thing on PDP-11s. However the syntax IS,
>> and especially can be MADE, a bit obscure. More
>> 'obvious', 'self-documenting' langs DO have an
>> advantage.
>>
>
> C is just shorthand for assembly, and assembly,
> i.e. machine, language is the language to which
> EVERYTHING else reduces.
>
> Yes, C is just shorthand for assembly. Whenever I
> write C code I can always "see" the assembly instructions
> that lie beneath every C statement.
>
> In fact, when it comes to SIMD programming, there are C
> functions known as "intrinsics" that allow direct access
> to SIMD hardware assembly instruction (e.g. SSE2, AVX).
> (These do not exist for any other language.)
>
>
> Conclusion:
>
> Those who understand the machine use C (assembly) and only
> C.
>
> All dumb-fuck idiots and retards, of which there are hordes
> in commercial (i.e. paid) programming, MUST use other "crutch"
> languages.

We 'old guys' did a fair amount of ASM back in
the day - microcontrollers, even up to early CP/M
and DOS before there were (affordable) high-level
compilers.

Knew one ultra-geek who wrote clones of popular
video games for C64/PET. He was one of those
'critically intelligent' people - right on the
very edge. Ever see that old Val Kilmer movie
about the genius school ? He was kinda like the
guy who lived inside the walls. He didn't even
do ASM, but wrote in raw 6502 binary. Said it
gave him a buzz ! Watched him do it.

It's very frustrating - being JUST smart enough to
really smell the ultra-IQ, see its possibilities,
but knowing you can never GET there :-)

I downloaded a copy of the ancient Aztec 'C'
compiler for CP/M-86. Haven't done anything
with it yet. CP/M-86 WILL run on VirtualBox.
Aztec was well-respected back in the day.
The most interesting feature though is the
MANUAL ... very deep into optimization and
smarter bit-field representations and ops.
You do NOT see that anymore. Those people
REALLY knew their product and wanted you to
know ALL the task-specific options.

On 2024-10-06, 186282@ud0s4.net <186283@ud0s4.net> wrote:

> We 'old guys' did a fair amount of ASM back in
> the day - microcontrollers, even up to early CP/M
> and DOS before there were (affordable) high-level
> compilers.

Those of us in the mainframe world wrote a lot of
assembly language too, e.g. for the IBM 360 family.
Back when memory was really tight, you might not
even be able to run a compiler (although RPG would
run in 16K or less). And even if you had a compiler,
the resulting code might not fit into memory for
anything other than trivial applications.

> Knew one ultra-geek who wrote clones of popular
> video games for C64/PET. He was one of those
> 'critically intelligent' people - right on the
> very edge. Ever see that old Val Kilmer movie
> about the genius school ? He was kinda like the
> guy who lived inside the walls. He didn't even
> do ASM, but wrote in raw 6502 binary. Said it
> gave him a buzz ! Watched him do it.
>
> It's very frustrating - being JUST smart enough to
> really smell the ultra-IQ, see its possibilities,
> but knowing you can never GET there :-)

That's pretty amazing, all right. I could toggle
code in through the front panel, though; sometimes
I would patch a loaded program to save the time
it would take to re-assemble it. (Programmers had
rock-bottom priority on the machine, so there was
a strong incentive to make the most of what time
you could get.) IBM 360 machine code was relatively
straightforward, so it wasn't quite as hard to do
as on many microprocessors.

> I downloaded a copy of the ancient Aztec 'C'
> compiler for CP/M-86. Haven't done anything
> with it yet. CP/M-86 WILL run on VirtualBox.
> Aztec was well-respected back in the day.
> The most interesting feature though is the
> MANUAL ... very deep into optimization and
> smarter bit-field representations and ops.
> You do NOT see that anymore. Those people
> REALLY knew their product and wanted you to
> know ALL the task-specific options.

Aztec had a C compiler for the Amiga which was
pretty good if you could pony up the bucks.
I wrote an Amiga assembler and open-sourced
it. Matt Dillon hooked it up to the C compiler
that he had written, which emitted assembly code.
The result was a complete, freely-distributable
C compiler for the Amiga.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

On Sun, 06 Oct 2024 06:05:38 GMT, Charlie Gibbs wrote:

> IBM 360 machine code was relatively
> straightforward, so it wasn't quite as hard to do as on many
> microprocessors.

There was the handy little reference card that would fit nicely into a
pocket protector :) I may be thinking of another processor but as I
recall you could twiddle octal locations in the opcodes.

On 2024-10-06, rbowman <bowman@montana.com> wrote:

> On Sun, 06 Oct 2024 06:05:38 GMT, Charlie Gibbs wrote:
>
>> IBM 360 machine code was relatively
>> straightforward, so it wasn't quite as hard to do as on many
>> microprocessors.
>
> There was the handy little reference card that would fit nicely into a
> pocket protector :)

Yup. We sometimes called a "fig leaf". I got mine almost completely
memorized at about the time it fell apart.

https://www.computerhistory.org/revolution/mainframe-computers/7/164/659

> I may be thinking of another processor but as I
> recall you could twiddle octal locations in the opcodes.

Perhaps - the 360 did things completely in hex.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

186282@ud0s4.net <186283@ud0s4.net> wrote:
> On 9/24/24 3:04 PM, Lester Thorpe wrote:
>> On Tue, 24 Sep 2024 02:45:16 -0400, 186282@ud0s4.net wrote:
>>
>>>
>>> Me, I'd rather use 'C' ... which was a brand new
>>> language when I got into computers - it was the
>>> Cool New Thing on PDP-11s. However the syntax IS,
>>> and especially can be MADE, a bit obscure. More
>>> 'obvious', 'self-documenting' langs DO have an
>>> advantage.
>>>
>>
>> C is just shorthand for assembly, and assembly,
>> i.e. machine, language is the language to which
>> EVERYTHING else reduces.
>>
>> Yes, C is just shorthand for assembly. Whenever I
>> write C code I can always "see" the assembly instructions
>> that lie beneath every C statement.
>>
>> In fact, when it comes to SIMD programming, there are C
>> functions known as "intrinsics" that allow direct access
>> to SIMD hardware assembly instruction (e.g. SSE2, AVX).
>> (These do not exist for any other language.)
>>
>>
>> Conclusion:
>>
>> Those who understand the machine use C (assembly) and only
>> C.
>>
>> All dumb-fuck idiots and retards, of which there are hordes
>> in commercial (i.e. paid) programming, MUST use other "crutch"
>> languages.
>
>
> We 'old guys' did a fair amount of ASM back in
> the day - microcontrollers, even up to early CP/M
> and DOS before there were (affordable) high-level
> compilers.
>
> Knew one ultra-geek who wrote clones of popular
> video games for C64/PET. He was one of those
> 'critically intelligent' people - right on the
> very edge. Ever see that old Val Kilmer movie
> about the genius school ? He was kinda like the
> guy who lived inside the walls. He didn't even
> do ASM, but wrote in raw 6502 binary. Said it
> gave him a buzz ! Watched him do it.
>
> It's very frustrating - being JUST smart enough to
> really smell the ultra-IQ, see its possibilities,
> but knowing you can never GET there :-)
>
> I downloaded a copy of the ancient Aztec 'C'
> compiler for CP/M-86. Haven't done anything
> with it yet. CP/M-86 WILL run on VirtualBox.
> Aztec was well-respected back in the day.
> The most interesting feature though is the
> MANUAL ... very deep into optimization and
> smarter bit-field representations and ops.
> You do NOT see that anymore. Those people
> REALLY knew their product and wanted you to
> know ALL the task-specific options.
>
>

I used Aztec C on PC-DOS back in the day. It was the first C compiler I
ever used.

--
Pete