Loongson 3A5000?

[gareth evans]

AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.

I've googled unsuccessfully so any pointers
to this ISA?

(As always, real computer scientists program
in assembler :-) )

[Thomas Koenig]

(x-post, f-up).

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?
(As always, real computer scientists program
in assembler :-) )

Maybe this question would be better answered in comp.arch?

[Charlie Gibbs]

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?
(As always, real computer scientists program
in assembler :-) )

As opposed to the CS weenies for whom the higher-level the
language, the better? That's why I dropped out of university
and found work in the Real World [tm].

[Scott Lurndal]

Post by Charlie Gibbs

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?
(As always, real computer scientists program
in assembler :-) )

As opposed to the CS weenies for whom the higher-level the
language, the better?

This seems to paint with far to broad of a brush.

Post by Charlie Gibbs
That's why I dropped out of university
and found work in the Real World [tm].

I challenge anyone to write and maintain a modern
and useful real-world application in assembler. Most
programmers realized that higher level languages were
to be preferred around the time of the first COBOL report.

[gareth evans]

Post by Scott Lurndal

Post by Charlie Gibbs

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?
(As always, real computer scientists program
in assembler :-) )

As opposed to the CS weenies for whom the higher-level the
language, the better?

This seems to paint with far to broad of a brush.

Post by Charlie Gibbs
That's why I dropped out of university
and found work in the Real World [tm].

I challenge anyone to write and maintain a modern
and useful real-world application in assembler. Most
programmers realized that higher level languages were
to be preferred around the time of the first COBOL report.

If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,
subject to execution environmental considerations such as
speed for realtime systems.

[Scott Lurndal]

Post by gareth evans

Post by Scott Lurndal

Post by Charlie Gibbs

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?
(As always, real computer scientists program
in assembler :-) )

As opposed to the CS weenies for whom the higher-level the
language, the better?

This seems to paint with far to broad of a brush.

Post by Charlie Gibbs
That's why I dropped out of university
and found work in the Real World [tm].

I challenge anyone to write and maintain a modern
and useful real-world application in assembler. Most
programmers realized that higher level languages were
to be preferred around the time of the first COBOL report.

If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,
subject to execution environmental considerations such as
speed for realtime systems.

At 100x the development cost, and with a much larger potential
for error.

[Ahem A Rivet's Shot]

On Thu, 22 Apr 2021 21:20:43 +0100

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

It makes you wonder why people spend so much time on language
design doesn't it. Personally I'd hate to write a kernel module in COBOL,
a payroll package in Prolog, a web browser in Forth or a boot loader in
JavaScript.

[gareth evans]

Post by Ahem A Rivet's Shot
On Thu, 22 Apr 2021 21:20:43 +0100

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

It makes you wonder why people spend so much time on language
design doesn't it. Personally I'd hate to write a kernel module in COBOL,
a payroll package in Prolog, a web browser in Forth or a boot loader in
JavaScript.

As I said in closing, except for environmental considerations.

[Richard Thiebaud]

Post by gareth evans

Post by Ahem A Rivet's Shot
On Thu, 22 Apr 2021 21:20:43 +0100

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

    It makes you wonder why people spend so much time on language
design doesn't it. Personally I'd hate to write a kernel module in COBOL,
a payroll package in Prolog, a web browser in Forth or a boot loader in
JavaScript.

As I said in closing, except for environmental considerations.

All programs have environment consideration.

[Charlie Gibbs]

Post by Ahem A Rivet's Shot
On Thu, 22 Apr 2021 21:20:43 +0100

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

It makes you wonder why people spend so much time on language
design doesn't it. Personally I'd hate to write a kernel module in COBOL,
a payroll package in Prolog, a web browser in Forth or a boot loader in
JavaScript.

A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

[g***@gmail.com]

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Pfffff! That's my brain broken for the day. I'm sure I've forgotten all the COBOL I learned in college. Is there a free version,
that interfaces with Windows and does graphics and stuff? Partly I'd like to flex my muscles, partly I'd just like to be reminded
how bizarre it was. "Visual COBOL"!

Oh god, not I've got to go look and see if it exists...

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Peter Flass]

Post by g***@gmail.com

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Pfffff! That's my brain broken for the day. I'm sure I've forgotten all
the COBOL I learned in college. Is there a free version,
that interfaces with Windows and does graphics and stuff? Partly I'd like
to flex my muscles, partly I'd just like to be reminded
how bizarre it was. "Visual COBOL"!
Oh god, not I've got to go look and see if it exists...

There’s a Gnu COBOL

Post by g***@gmail.com
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Scott Lurndal]

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Somewhere in a box in storage I have a listing of an 8080 assembler
written in Fortran.

[Charlie Gibbs]

Post by Scott Lurndal

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Somewhere in a box in storage I have a listing of an 8080 assembler
written in Fortran.

Hmm, I wonder whether it's the same one. :-)

The Univac OS/3 assembler was much like the IBM DOS/360 assembler,
warts and all. One rumour says that someone found source code in the
trunk of a car somewhere. (Another rumour says IBM wanted it found.)

Incidentally, I've just scanned a copy of SY33-8567-0 DOS/VS Assembler Logic.
Documentation run wild...

[Peter Flass]

Post by Scott Lurndal

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Somewhere in a box in storage I have a listing of an 8080 assembler
written in Fortran.

PL/M was written in FORTRAN. Before C FORTRAN was the universal language.

[Scott Lurndal]

Post by Peter Flass

Post by Scott Lurndal

Post by Charlie Gibbs
A friend once wrote an 8080 assembler in COBOL. It ran rings
around Univac's assembler - which was written in Fortran.

Somewhere in a box in storage I have a listing of an 8080 assembler
written in Fortran.

PL/M was written in FORTRAN. Before C FORTRAN was the universal language.

I'd argue that COBOL was as universal as FORTRAN in the 1960s. I've even
seen disk defragmenters written in COBOL (Burroughs SQUASH utility).

[g***@gmail.com]

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual definition of "modern". He's bang right. Is "historically modern"
even an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

Beyond a certain point, any attempt to fix errors would only introduce more errors. You could not write the majority of stuff on
most people's desktops in asm. That's why we have compilers. If we were to assume, hypothetically, that a team of thousands spend
many years on speccing out and planning a program to the point that it COULD be written in asm, then those specs themselves will
essentially just be some new programming language. The specs and plans would need systems of writing to be designed, just to be
able to write them consistently and logically. They would need paradigms and their own verbiage. A language.

And it'd STILL fuck up the more you tried to fix it. A moonshot would be simpler.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Dan Espen]

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern" even
an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.

HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

[Thomas Koenig]

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.

Does HLASM help there?

[Peter Flass]

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

[Scott Lurndal]

Post by Peter Flass

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

at the end of a paper listing, no doubt.

[Dan Espen]

Post by Scott Lurndal

Post by Peter Flass

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

at the end of a paper listing, no doubt.

No, embedded in your online listing.
I didn't have to refer to it much since I did all my editing with Emacs
on a Linux system so I could find registers pretty quickly. But if I
needed to spot a register that hadn't been used yet, the cross reference
was a good place to go.

[Peter Flass]

Post by Scott Lurndal

Post by Peter Flass

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

at the end of a paper listing, no doubt.

How else should it do it? Few listings are actual dead trees these days,
anyway.

[Thomas Koenig]

Post by Peter Flass
Few listings are actual dead trees these days,
anyway.

That is one of the few things I miss about mainframes - the output
on large continuous form paper with green bars (so as not to confuse
different lines) and a decent number of columns.

[Charlie Gibbs]

Post by Thomas Koenig

Post by Peter Flass
Few listings are actual dead trees these days,
anyway.

That is one of the few things I miss about mainframes - the output
on large continuous form paper with green bars (so as not to confuse
different lines) and a decent number of columns.

For me, that problem went away once screen resolution went beyond VGA.
One of my always-open CLI windows is 80 columns wide by the height of
the screen (50-something lines). If I expand it to full screen it's
much wider than the 132 characters we got on paper.

I was lucky enough to work in a shop whose standard was 8 1/2 x 14
paper at 8 lines per inch (which green bars made readable), and I
later persuaded several other shops to switch. It was much easier
to spread out a couple of listings on your desk, and it actually got
two more lines per page than 11-inch-deep paper at 6 lpi. And, you
could file it in standard legal-size file folders and cabinets,
rather than spending big bucks on fancy stuff from Wright Line.

[g***@gmail.com]

Post by Thomas Koenig
That is one of the few things I miss about mainframes - the output
on large continuous form paper with green bars (so as not to confuse
different lines) and a decent number of columns.

My Nana used to bring big piles of that to our house when I was a kid! The non-bar side was just blank paper so you could draw on
it endlessly. There was some nonsense or other on the green side. I remember her telling me it was a Burroughs mainframe they
used, all on CRT terminals and apparently a fair bit of printout. Even in the 1980s! Very nostalgic for different reasons.

BTW do we need to still do 80 columns these days? Surely nobody is reading this on a terminal. We're all on GUIs, right? I decided
on 130 characters, still wastes half the screen, but my eyes don't need to move so much as I read it.

I propose we all add a few characters to the wrap limit. Make use of all that empty white! That screen is powered by fossil fuels,
so get the most out of it!

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Peter Flass]

Post by g***@gmail.com

Post by Thomas Koenig
That is one of the few things I miss about mainframes - the output
on large continuous form paper with green bars (so as not to confuse
different lines) and a decent number of columns.

My Nana used to bring big piles of that to our house when I was a kid!
The non-bar side was just blank paper so you could draw on
it endlessly. There was some nonsense or other on the green side. I
remember her telling me it was a Burroughs mainframe they
used, all on CRT terminals and apparently a fair bit of printout. Even in
the 1980s! Very nostalgic for different reasons.
BTW do we need to still do 80 columns these days? Surely nobody is
reading this on a terminal. We're all on GUIs, right? I decided
on 130 characters, still wastes half the screen, but my eyes don't need
to move so much as I read it.

You’re an outlier, I think. The limit is the ability of the reader to
follow across a very long line. magic number, but it’s not a bad
approximation. I used to use 160 on my 3290, but that had the nice feature
of a light dashed underline all the way across that would follow the cursor
down the page to keep my eyes on the right line.

Post by g***@gmail.com
I propose we all add a few characters to the wrap limit. Make use of all
that empty white! That screen is powered by fossil fuels,
so get the most out of it!
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Joy Beeson]

Post by g***@gmail.com
I propose we all add a few characters to the wrap limit. Make use of all that empty white! That screen is powered by fossil fuels,
so get the most out of it!

I rotated the screen I use for readng text ninety degrees.

And always wrap at less than 78 characters.

[Kerr-Mudd, John]

On Sat, 24 Apr 2021 21:33:35 GMT

Post by g***@gmail.com

Post by Thomas Koenig
That is one of the few things I miss about mainframes - the output
on large continuous form paper with green bars (so as not to confuse
different lines) and a decent number of columns.

My Nana used to bring big piles of that to our house when I was a kid! The non-bar side was just blank paper so you could draw on
it endlessly. There was some nonsense or other on the green side. I remember her telling me it was a Burroughs mainframe they
used, all on CRT terminals and apparently a fair bit of printout. Even in the 1980s! Very nostalgic for different reasons.
BTW do we need to still do 80 columns these days? Surely nobody is reading this on a terminal. We're all on GUIs, right? I decided
on 130 characters, still wastes half the screen, but my eyes don't need to move so much as I read it.

I was just wonderng whether to complain about that! 72 is my
preference. (See what's happened to your text?)

Post by g***@gmail.com
I propose we all add a few characters to the wrap limit. Make use of all that empty white! That screen is powered by fossil fuels,
so get the most out of it!
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Niklas Karlsson]

Post by g***@gmail.com
BTW do we need to still do 80 columns these days? Surely nobody is reading this on a terminal. We're all on GUIs, right? I decided
on 130 characters, still wastes half the screen, but my eyes don't need to move so much as I read it.

I'm not anti-GUI, but I run a Linux VM so I can do certain things in a
terminal (well, a PuTTY if logging in from Windows), including reading
news. I just feel the medium is well suited to that.

It's also handy to be able to SSH to it from anywhere on the net and
attach to the screen session (one of these years I should explore
tmux...), and instantly have all my usual tools and data available.

Niklas

[Dan Espen]

Post by Peter Flass

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

That's helpful too.
So is only using 1 base register for executable code so you don't tie up
all your registers.

[Peter Flass]

Post by Dan Espen

Post by Peter Flass

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

It gives you a cross-reference if register usage.

That's helpful too.
So is only using 1 base register for executable code so you don't tie up
all your registers.

Right. It’s rarely necessary, if you write modular code, to write a module
bigger than 4K.

[Dan Espen]

Post by Thomas Koenig

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

What I find most difficult in writing assembler is to remember which
register contains which variable at any given time.
Does HLASM help there?

You can equate a register number to a register function, but that way
lies madness. Better to use DSECTS and USING so that you're not
referring to registers that often. Also set aside registers as work
registers not holding values over long stretches of code. For example,
use R1 to increment a counter, store the counter then use it for
something else.

The last code I supported would signal which registers it was using
at subroutine entry then drop those registers at subroutine exit. So the
registers in use were locally visible.

[Charlie Gibbs]

Post by Dan Espen
You can equate a register number to a register function, but that way
lies madness. Better to use DSECTS and USING so that you're not
referring to registers that often. Also set aside registers as work
registers not holding values over long stretches of code. For example,
use R1 to increment a counter, store the counter then use it for
something else.

Registers 15, 0, and 1 are great for BXLE loops.

[Peter Flass]

Post by Dan Espen

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern" even
an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced. With a good macro package it's just about as easy
to read and write as any high level language.

+1

[Scott Lurndal]

Post by Dan Espen

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern" even
an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.

It is not difficult to use in any modern incarnation (post 80286),
it is quite straightforward. Just as much as any other macro
assembler for any other architecture, including z-series.

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced.

That were written decades ago. There are very few, if any,
new applications written in HLASM.

[Dan Espen]

Post by Scott Lurndal

Post by Dan Espen

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern" even
an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.

It is not difficult to use in any modern incarnation (post 80286),
it is quite straightforward. Just as much as any other macro
assembler for any other architecture, including z-series.

Yeah I said "seems". Not much experience with MASM. I think the
last time this came up someone mentioned structured macros for MASM.
My bias is probably based on what I'm more familiar with.

Post by Scott Lurndal

Post by Dan Espen
HLASM (IBM mainframes) on the other hand is relatively easy to use and
there are loads of large applications written in HLASM that are actively
maintained and enhanced.

That were written decades ago. There are very few, if any,
new applications written in HLASM.

Entire new applications, probably true.
When you're dealing with a large application already written in
Assembler and you need to add modules, sometimes Assembler is
the easiest choice.

I'm retired about 5 years now, but back then I was frequently writing
new stuff in HLASM.

[Scott Lurndal]

Post by Dan Espen

Post by Scott Lurndal

Post by Dan Espen

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern" even
an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.

It is not difficult to use in any modern incarnation (post 80286),
it is quite straightforward. Just as much as any other macro
assembler for any other architecture, including z-series.

Yeah I said "seems". Not much experience with MASM. I think the
last time this came up someone mentioned structured macros for MASM.
My bias is probably based on what I'm more familiar with.

There were assemblers for x86 pre-microsoft, and the x86 unix
assemblers (and GNU gas) are quite powerful.

But, the main point was that post-286, segmentation wasn't a
condideration for assembler programmers - the address space
was a flat 32-bit space which made data layout much easier
and eliminated the use of segment registers.

[Charlie Gibbs]

Post by Dan Espen

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
A well-designed and properly thought-out program design will work well
irrespective of the language in which it is coded,

Dude do you even know what assembler IS?

X86 Assembler seems like a difficult language to use.

That's what nudged me away from assembly language programming.
Fortunately, C came along at just the right time.

[gareth evans]

Post by g***@gmail.com

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual definition of "modern". He's bang right. Is "historically modern"
even an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

Dude do you even know what assembler IS?
Beyond a certain point, any attempt to fix errors would only introduce more errors. You could not write the majority of stuff on
most people's desktops in asm. That's why we have compilers. If we were to assume, hypothetically, that a team of thousands spend
many years on speccing out and planning a program to the point that it COULD be written in asm, then those specs themselves will
essentially just be some new programming language. The specs and plans would need systems of writing to be designed, just to be
able to write them consistently and logically. They would need paradigms and their own verbiage. A language.
And it'd STILL fuck up the more you tried to fix it. A moonshot would be simpler.

OK, so you admit to being an incompetent assembly language programmer.

[g***@gmail.com]

Post by gareth evans
OK, so you admit to being an incompetent assembly language programmer.

Right tool for the right job, mate. I've written a tiny amount of assembler. Generally I'd use C. As they say "All the advantages
of assembler, with all the disadvantages of assembler!"

You could argue that a sophisticated enough macro assembler is a language in itself, making up intellectual constructs to hide you
from the metal. Or at least taking care of the tedious metal-polishing. You could argue that C isn't too far from being a macro
assembler, it's certainly the child of them.

So, you admit to using a terrible method that's bound to fail for any large program, just out of stubborness and a fetish for
something nobody does any more? Have you an example of a big application written in asm? Did the paperwork end up being bigger
than the computer?


------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[gareth evans]

Post by g***@gmail.com

Post by gareth evans
OK, so you admit to being an incompetent assembly language programmer.

Right tool for the right job, mate. I've written a tiny amount of assembler. Generally I'd use C. As they say "All the advantages
of assembler, with all the disadvantages of assembler!"
You could argue that a sophisticated enough macro assembler is a language in itself, making up intellectual constructs to hide you
from the metal. Or at least taking care of the tedious metal-polishing. You could argue that C isn't too far from being a macro
assembler, it's certainly the child of them.
So, you admit to using a terrible method that's bound to fail for any large program, just out of stubborness and a fetish for
something nobody does any more? Have you an example of a big application written in asm? Did the paperwork end up being bigger
than the computer?

You've only written a tiny amount of assembler?

Why then do you think that the paperwork for an assembler program is
greater than that for a HLL?

[g***@gmail.com]

Post by gareth evans
Why then do you think that the paperwork for an assembler program is
greater than that for a HLL?

Because programming languages abstract stuff away. They take care of things for you. If you set a variable in most languages,
you'd no need to know where it's going. You can use pointers, in C or some BASICs (the ugly ones) to get them, but you don't need
to know where they're pointing. The grammar and language is richer. It's the equivalent of typing a novel on a word processor, vs
being stuck in a hospital bed and having to choose each letter by sucking on a tube.

When I say paperwork I'm envisaging a BIG project. In asm you have to manage so much more stuff manually, to keep track of it all.
To keep it well-designed and properly thought-out. Is there a large asm project you can think of as an example? One that needs
many programmers?

Sure asm can be good for little hacks, but it was the first programming language (after keying in opcodes in hex). Others have
been invented since, and most of the world's programmers appreciate them for all the help they are, for letting you think in that
particular logical programmer way, without having to figure out which opcodes and which registers and which RAM you're going to be
using. The little ASM I've done, put my brain in a very confined and oddly cubic space. You have to think like a CPU, and CPUs
aren't designed to help people like languages are, they're designed to work within the limits of electronics and the crazy torture
they perform on silicon these days. Modern programmers think in abstracts and algorithms, not, essentially, which voltage on which
line is going to connect the ALU to this particular register.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[gareth evans]

Post by g***@gmail.com

Post by gareth evans
Why then do you think that the paperwork for an assembler program is
greater than that for a HLL?

When I say paperwork I'm envisaging a BIG project. In asm you have to manage so much more stuff manually, to keep track of it all.
To keep it well-designed and properly thought-out.

The paperwork for all projects ends at module, or even procedure,
specifications, irrespective of the language employed, and irrespective
of the language employed the concepts
of, "well-designed and properly thought-out" should apply.

For example, to resolve algorithmic complexity, I use what
used to be BS6224, which was a vast improvement over
flowcharting because it had the high level concepts
of loops, conditionals and cases/switches as single
symbols.

I have never coded off-the-cuff.

Post by g***@gmail.com
... The little ASM I've done, put my brain in a very confined and oddly cubic space....

That's all you ever needed to say!

[Peter Flass]

Post by g***@gmail.com

Post by gareth evans
OK, so you admit to being an incompetent assembly language programmer.

Right tool for the right job, mate. I've written a tiny amount of
assembler. Generally I'd use C. As they say "All the advantages
of assembler, with all the disadvantages of assembler!"

This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft. Probably the cross-compilers for embedded
systems are still relatively clean.

Post by g***@gmail.com
You could argue that a sophisticated enough macro assembler is a language
in itself, making up intellectual constructs to hide you
from the metal. Or at least taking care of the tedious metal-polishing.
You could argue that C isn't too far from being a macro
assembler, it's certainly the child of them.
So, you admit to using a terrible method that's bound to fail for any
large program, just out of stubborness and a fetish for
something nobody does any more? Have you an example of a big application
written in asm? Did the paperwork end up being bigger
than the computer?
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[g***@gmail.com]

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft. Probably the cross-compilers for embedded
systems are still relatively clean.

I think a lot of that might be to do with the little dance programs have to do with the operating system, stick corks in the
necessary holes. That would explain why embedded systems still stay clean. That, and necessity for 8K flash and 256 bytes RAM or
whatever you've got. The C you're complaining about wouldn't be the other kind of "cross" would it? ++ ? Sign of the double cross!

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Peter Flass]

Post by g***@gmail.com

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft. Probably the cross-compilers for embedded
systems are still relatively clean.

I think a lot of that might be to do with the little dance programs have
to do with the operating system, stick corks in the
necessary holes. That would explain why embedded systems still stay
clean. That, and necessity for 8K flash and 256 bytes RAM or
whatever you've got. The C you're complaining about wouldn't be the other
kind of "cross" would it? ++ ? Sign of the double cross!

Gcc pulls in a lot of stuff, even for a minimal program. In olden days you
could write a C program for DOS to read data from the console and display
results without needing anything but your own code, no libraries, etc.

Post by g***@gmail.com
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Scott Lurndal]

Post by Peter Flass

Post by g***@gmail.com

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft. Probably the cross-compilers for embedded
systems are still relatively clean.

I think a lot of that might be to do with the little dance programs have
to do with the operating system, stick corks in the
necessary holes. That would explain why embedded systems still stay
clean. That, and necessity for 8K flash and 256 bytes RAM or
whatever you've got. The C you're complaining about wouldn't be the other
kind of "cross" would it? ++ ? Sign of the double cross!

Gcc pulls in a lot of stuff, even for a minimal program.

Can you elaborate? How many programs have you written using
GCC?

It's been my experience that you can do anything you want with
GCC, including creating minimal programs that have a microscopic
memory footprint.

It really depends on what you want to do.

Post by Peter Flass
In olden days you
could write a C program for DOS to read data from the console and display

In the old days (pre 1982), there wasn't a C compiler for MSDOS.

In any case, you can still write such a program in C, using GCC or ICC
or most other C compilers using just your own code. If you're masochistic
enough to want to do so. You don't _need_ the libraries, but you'd
be crazy not to use them in these modern times.

[Thomas Koenig]

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language,

C is still quite close to the hardware, so to speak. You look at
code, you can see pretty much what it does in assembler, or
you will see a function call.

The only exception that I can remember right now is struct
assignment, which will probably be translated to a memcpy.

Post by Peter Flass
with all the plusses and minusses of that, but
it comes with a lot of cruft.

The standard library is rather big now, yes.

Post by Peter Flass
Probably the cross-compilers for embedded
systems are still relatively clean.

Cross compilation is usually done with a full-strength compiler
(why not?). Of course, for an embeddes system, you usually have
a free-standing implementation, so most of the standard library
will probably not be there (what is "printf" supposed to do on
a toaster?)

[gareth evans]

Post by Thomas Koenig

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language,

C is still quite close to the hardware, so to speak. You look at
code, you can see pretty much what it does in assembler, or
you will see a function call.

AIUI, the cast operator, such as (int *)(0xFFF0), was introduced
specifically for access to hardware I/O

[Scott Lurndal]

Post by gareth evans

Post by Thomas Koenig

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language,

C is still quite close to the hardware, so to speak. You look at
code, you can see pretty much what it does in assembler, or
you will see a function call.

AIUI, the cast operator, such as (int *)(0xFFF0), was introduced
specifically for access to hardware I/O

No, that's not the case. Casts have many usages, and the usage
above is a natural consequence of the indirection operator introduced
in the first versions of C.

While they can be (and are) used to access hardware I/O memory
mapped registers, it is not the raison d'etre for the cast operator.

Not all architectures at the time used memory mapped I/O registers;
many used special instructions (for which the C code would often
call a function written in assembler, for example the Intel x86
"in" and "out" instructions).

[Scott Lurndal]

Post by Thomas Koenig

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language,

C is still quite close to the hardware, so to speak. You look at
code, you can see pretty much what it does in assembler, or
you will see a function call.
The only exception that I can remember right now is struct
assignment, which will probably be translated to a memcpy.

Depending on the size of the struct, it may be copied
with a single move (up to 128 bits on processors like
ARMv8) or a SIMD instruction (up to 2048-bits wide on
some processors).

A couple of LOAD PAIR instructions can load 256 bits
into four registers and a pair of STORE PAIR instructions
will store those. There are a lot of small structs in
code.

Even memcpy, when not inlined by the compiler, uses standard
data movement instructions, optimized for best performace for
several size groupings (e.g. < 32 bytes, 32-128 bytes, and
more than 128 bytes may use three different paths through
the memcpy function), often by using wider SIMD loads/stores
in a loop with prefetch instructions to draw future lines
into the cache before they're needed.

[Charlie Gibbs]

Post by Thomas Koenig
Cross compilation is usually done with a full-strength compiler
(why not?). Of course, for an embeddes system, you usually have
a free-standing implementation, so most of the standard library
will probably not be there (what is "printf" supposed to do on
a toaster?)

I'm not sure, but I do get a delightful image from _The Big Bang
Theory_ of Sheldon's Cylon toast.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 08:08:40 -0000 (UTC)

(what is "printf" supposed to do on a toaster?)

Print on the toast of course.

[a***@math.uni.wroc.pl]

Post by Peter Flass

Post by g***@gmail.com

Post by gareth evans
OK, so you admit to being an incompetent assembly language programmer.

Right tool for the right job, mate. I've written a tiny amount of
assembler. Generally I'd use C. As they say "All the advantages
of assembler, with all the disadvantages of assembler!"

This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it?s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft. Probably the cross-compilers for embedded
systems are still relatively clean.

I frequently look at assembler generated by C compilers. It is
no longer straightforward translation, but resulting code is
much better than in the past. In the past, especially with weaker
compiler ther was a lot of cruft like storing data in memory
only because source contains assignment. Now gcc can keep
data in registers and is reasonably smart in choice of
instructions. For 16-bit and 32-bit x86 code I used Borland C,
and it generated rather poor code. Already at that time gcc
was much better than Borland C, but now gcc generated code
has improved.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)

Post by a***@math.uni.wroc.pl
I frequently look at assembler generated by C compilers. It is
no longer straightforward translation, but resulting code is
much better than in the past.

It is often claimed that modern optimisers produce significantly
better (as in tighter and faster) code from high level languages than
skilled assembler programmers can manage.

[Thomas Koenig]

Post by Ahem A Rivet's Shot
On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)

Post by a***@math.uni.wroc.pl
I frequently look at assembler generated by C compilers. It is
no longer straightforward translation, but resulting code is
much better than in the past.

It is often claimed that modern optimisers produce significantly
better (as in tighter and faster) code from high level languages than
skilled assembler programmers can manage.

On average, and for longer pieces of code (>100 lines) used
in production: Almost universally.

For special cases, small examples and highly specialized stuff like
SIMD instructions: There, it is still possible to find examples
where compilers generate subobtimal code, and to actually do better.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)

Post by Thomas Koenig
On average, and for longer pieces of code (>100 lines) used
in production: Almost universally.
For special cases, small examples and highly specialized stuff like
SIMD instructions: There, it is still possible to find examples
where compilers generate subobtimal code, and to actually do better.

So for best results use a HLL, compile to assembler and optimise by
hand where possible.

[Owen Rees]

On Sun, 25 Apr 2021 21:05:08 +0100, Ahem A Rivet's Shot

Post by Ahem A Rivet's Shot
On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)

Post by Thomas Koenig
On average, and for longer pieces of code (>100 lines) used
in production: Almost universally.
For special cases, small examples and highly specialized stuff like
SIMD instructions: There, it is still possible to find examples
where compilers generate subobtimal code, and to actually do better.

So for best results use a HLL, compile to assembler and optimise by
hand where possible.

I disagree. For best results, fix the compiler to do a better job. That
way, the optimisation persists next time you compile the code without
the need for additional effort.

[Peter Flass]

Post by Owen Rees
On Sun, 25 Apr 2021 21:05:08 +0100, Ahem A Rivet's Shot

Post by Ahem A Rivet's Shot
On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)

Post by Thomas Koenig
On average, and for longer pieces of code (>100 lines) used
in production: Almost universally.
For special cases, small examples and highly specialized stuff like
SIMD instructions: There, it is still possible to find examples
where compilers generate subobtimal code, and to actually do better.

So for best results use a HLL, compile to assembler and optimise by
hand where possible.

I disagree. For best results, fix the compiler to do a better job. That
way, the optimisation persists next time you compile the code without
the need for additional effort.

Not really. As I said previously the programmer may know things a compiler
can’t. The compiler has to assume the worst case, generating checks for
errors where they can never occur (Hah! I’ve loaded Iron Spring PL/i with
lots of checks for “should not occur” conditions, and occasionally
encounter one). However, if the programmer knows that a certain variable
can only have values of (say) 1-5, (hopefully because he has checked for
this elsewhere), then there’s no need to do a range check.

I think that Ada, and probably other languages, (Bliss?) let you explicitly
state the constraints on the values variables can contain.

[Thomas Koenig]

Post by Ahem A Rivet's Shot
On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)

Post by Thomas Koenig
On average, and for longer pieces of code (>100 lines) used
in production: Almost universally.
For special cases, small examples and highly specialized stuff like
SIMD instructions: There, it is still possible to find examples
where compilers generate subobtimal code, and to actually do better.

So for best results use a HLL, compile to assembler and optimise by
hand where possible.

Certainly not "where possible".

If the performance is unacceptable, first see where the critical
time is actually spent. Take a good look at your algorithms and
data structures that are accessed in that place (array of structs
vs. struct of arrays? Linked list vs. array? n^2 algorithm?
What about cache locality? Too much indirect jumps through
object oriented stuff?

Try what the compiler has to offer. Did you try link-time and
profile-guided optimization? Did you compile for your actual
architecture?

If you have identified the problem, you can then isolate the
performance-critical code into its own function and possibly
rewrite it using compiler intrinsics or indeed assembler.
If you do that, keep your original HLL file around and run
extensive tests comparing the two.

However, keep in mind that there is no "optimized assembler"
for all of today's architectures, let alone tomorrow's, and
how people have been bitten trying memcpy() using AVX512...

[Peter Flass]

Post by Ahem A Rivet's Shot
On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)

Post by a***@math.uni.wroc.pl
I frequently look at assembler generated by C compilers. It is
no longer straightforward translation, but resulting code is
much better than in the past.

It is often claimed that modern optimisers produce significantly
better (as in tighter and faster) code from high level languages than
skilled assembler programmers can manage.

In the general case, I expect. For smaller sections of code a good
programmer can probably optimize as well as the compiler, and maybe better,
because the programmer knows things about the program that the compiler
doesn’t. However, no programmer would waste all that effort optimizing
every part of a large program.

[Scott Lurndal]

Post by Peter Flass

Post by g***@gmail.com

Post by gareth evans
OK, so you admit to being an incompetent assembly language programmer.

Right tool for the right job, mate. I've written a tiny amount of
assembler. Generally I'd use C. As they say "All the advantages
of assembler, with all the disadvantages of assembler!"

This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

And, with both languages, nothing requires that you use anything more
than a subset of the full language. One can still compile and run programs
that Dennis and Ken wrote in 1976 (albeit with special compiler flags
to invoke backward compatible translation behavior).

[John Levine]

Post by Scott Lurndal

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

The C language itself has gotten somewhat bigger but the library has exploded.

If you're on a system with dynamic linking that's not such a big deal
since every program shares the same copy of the library but on embdded
or standalone systems it's an issue. It's not like the good old days
when it was easy to fit interesting programs into a 64K address space.

[a***@math.uni.wroc.pl]

Post by John Levine

Post by Scott Lurndal

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it???s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

The C language itself has gotten somewhat bigger but the library has exploded.
If you're on a system with dynamic linking that's not such a big deal
since every program shares the same copy of the library but on embdded
or standalone systems it's an issue. It's not like the good old days
when it was easy to fit interesting programs into a 64K address space.

One of most important features of C is that language can work without
or with tiny runtime library. You use libraries (including "standard"
one) only when there is a gain. If main criterion is size, then
I use libraries when alternative code is comparable or bigger.
64K actually allows for lot of libraries. OTOH modern systems
have much more RAM than the old ones. It makes sense to optimize
for speed at cost of size. I am also "guilty" here: in one program
I have various compilation options. In the past it was possible
to compile program to about 16M code. Now smallest working option
gives closer to 40M, fastest one takes about 150M. I and other
folks normally use large and fast: by modern standards program
size is quite resonable and better speed is always welcome.

BTW. Old wisdom, AFAICS still valid today: once you exceed
critical (not very large) size smallest code is interpreted
bytecode, typically significantly smaller than native
machine code. So higher level language compiling to
bytecode can give smaller executable size than C or
assember.

[Thomas Koenig]

Post by John Levine

Post by Scott Lurndal

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

The C language itself has gotten somewhat bigger but the library has exploded.
If you're on a system with dynamic linking that's not such a big deal
since every program shares the same copy of the library

Unless it's on a VM, or in a docker container, or a combination...

Docker containers came into existence because shared libraries do
not always work correctly - if you want to have a program that
does the same thing everyhwere, you have to breakt that dependency.

I am, however, not sure what the advantage of a docker container
over a statically linked binary really is.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 20:01:03 -0000 (UTC)

Post by Thomas Koenig
I am, however, not sure what the advantage of a docker container
over a statically linked binary really is.

Docker containers can be anything from a single executable to a
complete development environment.

The other advantage is that you can layer configuration and
networking in as well as executables - coupled with an orchestration tool
(kubernetes almost exclusively these days) you can define a scalable data
centre crawling with services complete with multiple VPNs gluing it
together, all the authentication and authorisation specs - everything, all
in a single text file. Then hit a button and watch it spring into globally
distributed, load balanced, fault tolerant life in a ridiculously short
time. Then watch your AWS/Azure/Google bill start to mount as load comes
in - this sort of arrangement is very well suited to rented compute and
bandwidth.

OK somebody has to create all the docker images that you need
first, but most of them are (if you trust them) available publicly. The
more paranoid build their own.

[Kerr-Mudd, John]

On Sun, 25 Apr 2021 16:38:04 -0000 (UTC)

Post by John Levine

Post by Scott Lurndal

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

The C language itself has gotten somewhat bigger but the library has exploded.
If you're on a system with dynamic linking that's not such a big deal
since every program shares the same copy of the library but on embdded
or standalone systems it's an issue. It's not like the good old days
when it was easy to fit interesting programs into a 64K address space.

Feh! search "256 byte demo"
pong, tetris, invaders etc.

[Scott Lurndal]

Post by John Levine

Post by Scott Lurndal

Post by Peter Flass
This used to be true. In early days C added only a few bytes of overhead to
your object program, and generated straightforward code. Now it’s just
another high-level language, with all the plusses and minusses of that, but
it comes with a lot of cruft.

Do you use C, yourself? There's very little cruft in C. Now C++ on the
other hand....

The C language itself has gotten somewhat bigger but the library has exploded.
If you're on a system with dynamic linking that's not such a big deal
since every program shares the same copy of the library but on embdded
or standalone systems it's an issue. It's not like the good old days
when it was easy to fit interesting programs into a 64K address space.

Most of the embedded processors today are programmed in C (or in
some cases, C++). They don't use the libraries, so dynamic linking
doesn't matter. It's still possible to write very compact code in
C (and I spent a lot of time trying to fit programs into 64k on the
PDP-11 running V6 Unix).

[Vir Campestris]

Post by g***@gmail.com
Right tool for the right job, mate. I've written a tiny amount of assembler.

I haven't _written_ any assembler for _ages_ and when I have it's been
because I want really close control on what the program does.

Poking I/O ports need to happen when you ask it. Not much point in a
memory test that optimises part of the loop. Things like that.

Reading assembler? I was reading some ARM assembler last week to help
with debugging. Which is hard because I never learned it.

Andy

[gareth evans]

Post by Vir Campestris

Post by g***@gmail.com
Right tool for the right job, mate. I've written a tiny amount of assembler.

I haven't _written_ any assembler for _ages_ and when I have it's been
because I want really close control on what the program does.
Poking I/O ports need to happen when you ask it. Not much point in a
memory test that optimises part of the loop. Things like that.
Reading assembler? I was reading some ARM assembler last week to help
with debugging. Which is hard because I never learned it.

An acquaintance of mine using Delphi produced a very sophisticated
home automation system (Idratek) but had difficulty in assimilating
a 3rd party library.

Assembler nous on my part enabled me to drill down and diagnose that
there was a confliction between STDCALL and CDECL subroutine standards.

My guess is that CDECL was introduced only to assist the external
printf function which can have a variable number of parameters passed.

From the point of view of space optimisation, clearly STDCALL is
preferable because then the stack cleanup code exists only once.

[Scott Lurndal]

Post by gareth evans

Post by Vir Campestris

Post by g***@gmail.com
Right tool for the right job, mate. I've written a tiny amount of assembler.

I haven't _written_ any assembler for _ages_ and when I have it's been
because I want really close control on what the program does.
Poking I/O ports need to happen when you ask it. Not much point in a
memory test that optimises part of the loop. Things like that.
Reading assembler? I was reading some ARM assembler last week to help
with debugging. Which is hard because I never learned it.

An acquaintance of mine using Delphi produced a very sophisticated
home automation system (Idratek) but had difficulty in assimilating
a 3rd party library.
Assembler nous on my part enabled me to drill down and diagnose that
there was a confliction between STDCALL and CDECL subroutine standards.

STDCALL/CDECL is microsoft crap. Real operating systems use a
consistent and standardized calling sequence.

[Johann 'Myrkraverk' Oskarsson]

Post by g***@gmail.com

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual definition of "modern". He's bang right. Is "historically modern"
even an intelligible concept?

Post by gareth evans
A well-designed and properly thought-out program design will
work well irrespective of the language in which it is coded,

Dude do you even know what assembler IS?
Beyond a certain point, any attempt to fix errors would only introduce more errors. You could not write the majority of stuff on
most people's desktops in asm. That's why we have compilers. If we were to assume, hypothetically, that a team of thousands spend
many years on speccing out and planning a program to the point that it COULD be written in asm, then those specs themselves will
essentially just be some new programming language. The specs and plans would need systems of writing to be designed, just to be
able to write them consistently and logically. They would need paradigms and their own verbiage. A language.
And it'd STILL fuck up the more you tried to fix it. A moonshot would be simpler.

You do know that most or all of the no$ emulators for Windows are
written in assembler, by one person?

https://problemkaputt.de/index.htm

Just because /you/ can't develop and maintain things in asm, doesn't
mean other people can't. I am not sure I want to, or can do it even
so.

[Niklas Karlsson]

Post by Johann 'Myrkraverk' Oskarsson
You do know that most or all of the no$ emulators for Windows are
written in assembler, by one person?

An emulator is probably a pretty good use-case for assembly language.
Try an office suite, IDE, or such.

Niklas

[Scott Lurndal]

Post by Niklas Karlsson

Post by Johann 'Myrkraverk' Oskarsson
You do know that most or all of the no$ emulators for Windows are
written in assembler, by one person?

An emulator is probably a pretty good use-case for assembly language.
Try an office suite, IDE, or such.

I disagree. Vehemently. I write "emulators" for a living. Our current
emulator (for a very large System-On-Chip[*]) runs over 2 million SLOC
of C++ (with small amounts of C and Python). It's also highly multithreaded
for performance.

Writing that in assembler would take decades, and it would be impossible
to support and you'd never find enough qualified programmers that didn't
need extensive training before being useful.

We need to have the emulator working in advance of silicon availability
to allow OS, device driver developers and customers to prepare their
software so it is ready when they get the first silicon, so development
time is a key priority.

[*] Many ARMv8+ cores, bunches of DSP cores, packet processing coprocessors
including hardware crypto for AES, SHA (up through SHA512), SM3,
ECC et alia and hardware network controller supporting RSS, traffic shaping,
and protocol tunnelling, USB controllers, SATA controllers, MMC controllers,
SPI, I2C, I3C and GPIO controllers, cryptographically secure
random number generators, PCI Express controllers and a host of other features.

Takes a couple of minutes to boot SMP linux kernel on the emulator
to a busybox prompt; performance is a major consideration.

[gareth evans]

Post by Scott Lurndal

Post by Niklas Karlsson

Post by Johann 'Myrkraverk' Oskarsson
You do know that most or all of the no$ emulators for Windows are
written in assembler, by one person?

An emulator is probably a pretty good use-case for assembly language.
Try an office suite, IDE, or such.

I disagree. Vehemently. I write "emulators" for a living. Our current
emulator (for a very large System-On-Chip[*]) runs over 2 million SLOC
of C++ (with small amounts of C and Python). It's also highly multithreaded
for performance.
Writing that in assembler would take decades,

How long did it take in the languages that you cited?

[Niklas Karlsson]

Post by Scott Lurndal

Post by Niklas Karlsson
An emulator is probably a pretty good use-case for assembly language.
Try an office suite, IDE, or such.

I disagree. Vehemently. I write "emulators" for a living. Our current
emulator (for a very large System-On-Chip[*]) runs over 2 million SLOC
of C++ (with small amounts of C and Python). It's also highly multithreaded
for performance.

Okay, I'll take you at your word, but the emulators Johann was
referencing were for small 1980s micros like the Commodore 64. I assume
what you are emulating is very much something else.

Niklas

[g***@gmail.com]

Post by Scott Lurndal
Writing that in assembler would take decades, and it would be impossible
to support

Right! That's the point. There's some stuff that cannot be done in asm. Not because of any Turing-related principles, just because
in the real world, bugs exist, and a programmer's brain can only get so hot before it parachutes out of his head.

Yep, emulators are a good example of something that suits asm, at least of 8-bit game consoles. It's emulating hardware, that is
well defined and constant. Lots of little modules doing their thing, then reporting back. Well 4 or 5 modules, anyway. They're
actually way faster than they need to be on modern hardware, he may as well have written them in Javascript (and people have!).
With emulating, the console's hardware is the final arbiter, carved in stone. There's only one right way to do things, and you
have lists of which addresses do what. So less ambiguity, which is poisonous to computers.

There are also ancient family relationships between the x86 and the Z80, say, or the souped-up 8080 in the Gameboy that Nocash is
most famous for emulating. So you can take advantage of that sometimes, effectively running Gameboy code on the PC's CPU, at least
a few instructions' worth. The flags are in some cases the same. Back in the day, emulators had to be coded extremely well to run
at 100% speed, even for things like the SNES. 100% speed was a target on programmers' aims list. So, tight, simple code in a
controlled environment might be a good thing to do in assembler, particularly if it needs to be as fast as possible. Then again,
these days you'd be lucky to beat a C compiler, unless you know tricks that it doesn't.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Peter Flass]

Post by g***@gmail.com

Post by Scott Lurndal
Writing that in assembler would take decades, and it would be impossible
to support

Right! That's the point. There's some stuff that cannot be done in asm.
Not because of any Turing-related principles, just because
in the real world, bugs exist, and a programmer's brain can only get so
hot before it parachutes out of his head.

If you write modular programs, and test the low-level stuff, a big program
is just stringing together a bunch of small modules. Admittedly I don’t
write much assembler these days. It used to be my language of choice on IBM
mainframes.

Post by g***@gmail.com
Yep, emulators are a good example of something that suits asm, at least
of 8-bit game consoles. It's emulating hardware, that is
well defined and constant. Lots of little modules doing their thing, then
reporting back. Well 4 or 5 modules, anyway. They're
actually way faster than they need to be on modern hardware, he may as
well have written them in Javascript (and people have!).
With emulating, the console's hardware is the final arbiter, carved in
stone. There's only one right way to do things, and you
have lists of which addresses do what. So less ambiguity, which is poisonous to computers.
There are also ancient family relationships between the x86 and the Z80,
say, or the souped-up 8080 in the Gameboy that Nocash is
most famous for emulating. So you can take advantage of that sometimes,
effectively running Gameboy code on the PC's CPU, at least
a few instructions' worth. The flags are in some cases the same. Back in
the day, emulators had to be coded extremely well to run
at 100% speed, even for things like the SNES. 100% speed was a target on
programmers' aims list. So, tight, simple code in a
controlled environment might be a good thing to do in assembler,
particularly if it needs to be as fast as possible. Then again,
these days you'd be lucky to beat a C compiler, unless you know tricks that it doesn't.
------------------------------------------------------------------------
if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Ahem A Rivet's Shot]

On Sat, 24 Apr 2021 16:26:37 GMT

Post by Scott Lurndal
[*] Many ARMv8+ cores, bunches of DSP cores, packet processing
coprocessors including hardware crypto for AES, SHA (up through SHA512),
SM3, ECC et alia and hardware network controller supporting RSS, traffic
shaping, and protocol tunnelling, USB controllers, SATA controllers, MMC
controllers, SPI, I2C, I3C and GPIO controllers, cryptographically secure
random number generators, PCI Express controllers and a host of other features.

That is a little more complex than a 1980s game console. Sounds
like the core of a *really* nice workstation but I'm guessing it's for
server farm use.

[g***@gmail.com]

Post by Ahem A Rivet's Shot
That is a little more complex than a 1980s game console. Sounds
like the core of a *really* nice workstation but I'm guessing it's for
server farm use.

Hm, I dunno, what are the DSPs for? Unless it's for encoding video for one of those sites. Either Youtube or one of the Internet
TV stations, Netflix etc. DSPs for video and all the crazy advanced networking hardware to really optimise the bytes you send down
those tubes. Master the tubes!

Then again a lot of the features look contradictory, you couldn't use all of them for one job. So I suppose it's intended to be
versatile, a kitchen-sink CPU that nobody can turn down. No idea why you'd want MMC on there. Looks like it could maybe be a good
desktop CPU, depending on specs, but with all this network stuff...

Actually having the encryption etc on-chip means it's beyond reach of all but the most acid-wielding lunatics. Maybe it's part of
Intel's, or somebody else's, plans to have everything "secure" from switch-on through operating systems that send tendrils into
every program you run, key you press, and thing you connect to. Scott, if it's something evil, can you sabotage it in some way? In
return I'll nag Hollywood, I'll send them loads of letters, to demand they make a film about your heroism. Oh, actually, you might
wanna keep that quiet.

One other use of DSPs might be analysing video and photos... Cos it sounds like this customer wants lots of these. Oh dear. Never
mind, at least we can remember the days before Scott's chip got implanted into all our brains. If it lets us remember, that is.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Ahem A Rivet's Shot]

On Sat, 24 Apr 2021 23:09:14 GMT

Post by g***@gmail.com
Actually having the encryption etc on-chip means it's beyond reach of all
but the most acid-wielding lunatics.

This turns out not to be the case, most reasonably recent
processors have on chip encryption support and most operating systems
(including the open source ones) have drivers for it that expose a
kernel interface used by the likes of OpenSSL and GPG.

[g***@gmail.com]

Post by Niklas Karlsson
If C++ had only intended to solve the problems of C, it would have stopped
getting worse a long, long time ago. No such luck appears to obtain.
-- Garrett Wollman

I dunno why Bjarne chose C as the language to attach all his object stuff to. Rough old oily, rusty, nuts 'n' bolts C, home of the
crazy hack, memory management at least partly manual. 3 different kinds of brackets all over the place. And he chooses that to
attach balloons full of dreams to, a clean, happy, Danish programming language.

I don't understand the point of Java, either, really, the language is almost identical to C++. There are nice, friendly, civilised
languages available that don't let you wreck bits of hardware with the lack of a semicolon. Why not BASIC++ ? SQL++ ?

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Niklas Karlsson]

Post by g***@gmail.com
I dunno why Bjarne chose C as the language to attach all his object stuff to. Rough old oily, rusty, nuts 'n' bolts C, home of the
crazy hack, memory management at least partly manual. 3 different kinds of brackets all over the place. And he chooses that to
attach balloons full of dreams to, a clean, happy, Danish programming language.

I'm guessing working at Bell Labs in proximity to the C and Unix folks
was a big factor. Kernighan mentions it briefly in his recent Unix
memoir, defending Bjarne, along the lines of "every decision he made was
for a good reason", in his opinion.

Of course, C++ then was a different beast from C++ now. The language has
grown immensely.

Niklas

[Ahem A Rivet's Shot]

On 25 Apr 2021 11:23:20 GMT

Post by Niklas Karlsson
Of course, C++ then was a different beast from C++ now. The language has
grown immensely.

and that's *before* you look at the STL.

[Scott Lurndal]

Post by Ahem A Rivet's Shot
On 25 Apr 2021 11:23:20 GMT

Post by Niklas Karlsson
Of course, C++ then was a different beast from C++ now. The language has
grown immensely.

and that's *before* you look at the STL.

Fortunately, you are not -required- to use STL, or any of the C++ features
beyond C++ 2.1 if you don't need them.

I will grant that template instatation and compilation has become
far more efficient than it was in C++ 3.0, due to compiler advancements.

[Charlie Gibbs]

On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans

Post by gareth evans
If there were historically "modern" (for their times) applications
written in assembler then your challenge is meaningless.

I think he meant "modern" as in for THESE times, or the usual
definition of "modern". He's bang right. Is "historically modern"
even an intelligible concept?

Perhaps a better word would be "contemporary".

[Scott Lurndal]

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.

Loongson is an indiginous architecture designed in
China.

https://en.wikipedia.org/wiki/Loongson

[gareth evans]

Post by Scott Lurndal

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.

Loongson is an indiginous architecture designed in
China.
https://en.wikipedia.org/wiki/Loongson

Been there, hence my comment about unsuccessful googling.

That article only covers up to MIPS64 and does not
describe the 3A5000.

[g***@gmail.com]

Post by Scott Lurndal
Loongson is an indiginous architecture designed in
China.
https://en.wikipedia.org/wiki/Loongson

All the stuff on that page is MIPS. Notably that page doesn't mention the 3A5000. If I had to guess I'd guess MIPS too, but I
suppose OP could have guessed himself if that's all he wanted.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Scott Lurndal]

Post by g***@gmail.com

Post by Scott Lurndal
Loongson is an indiginous architecture designed in
China.
https://en.wikipedia.org/wiki/Loongson

All the stuff on that page is MIPS. Notably that page doesn't mention the 3A5000. If I had to guess I'd guess MIPS too, but I
suppose OP could have guessed himself if that's all he wanted.

Most of the articles I've seen indicate that it is still MIPS64. Some recent
articles (mostly translated from Chinese) tout a "new architecture". My
suspicion is that means a new "micro-architecture" rather than a new ISA.

We'll see when the Linley group (Microprocessor Report) cover it and when
Loongson make a presentation at the next Hot Chips conference at Stanford.

[g***@gmail.com]

Post by Scott Lurndal
Most of the articles I've seen indicate that it is still MIPS64. Some recent
articles (mostly translated from Chinese) tout a "new architecture". My
suspicion is that means a new "micro-architecture" rather than a new ISA.

I remember a graph saying it can emulate MIPS code at 100% speed, ARM at 80%, and x86 at 70%. At least IIRC. They mentioned 2000
instructions!?!? Is that some sort of VLIW thing, and they thing 2000 instructions is something to brag about? Maybe it's like ARM
with all the conditional instructions and they've worked out the combos to be more than 2000. Maybe 2048?

Maybe they're going for a kind of EPIC thing, where the chip is wide but simple, and the compiler does all the work? That would
allow some sort of semi-emulation thing where it can be set up to execute x86 instructions that have been run through the washing
machine, but then otherwise can run more-or-less native up until it traps something.

Who knows? The launch date will be as soon as they can break into the labs and steal the plans from Taiwan. Until then they're
torturing their own experts as hard as they can.

------------------------------------------------------------------------

if love is a drug, then, ideally, it's a healing, healthful drug... it's
kind of like prozac is supposed to work (without the sexual side
effects and long-term damage to the brain and psyche)

[Scott Lurndal]

Post by g***@gmail.com

Post by Scott Lurndal
Most of the articles I've seen indicate that it is still MIPS64. Some recent
articles (mostly translated from Chinese) tout a "new architecture". My
suspicion is that means a new "micro-architecture" rather than a new ISA.

I remember a graph saying it can emulate MIPS code at 100% speed, ARM at 80%, and x86 at 70%. At least IIRC. They mentioned 2000
instructions!?!? Is that some sort of VLIW thing, and they thing 2000 instructions is something to brag about? Maybe it's like ARM
with all the conditional instructions and they've worked out the combos to be more than 2000. Maybe 2048?

Only certain ARM instruction sets have conditional instructions (A32, T32).

- A32 (the ARMv5-v7 32-bit instructions set)
- T32 (The ARMv5-v7 16-bit instruction set also known as thumb)
- A64 (the 64-bit instruction set)
- NEON (the Advanced SIMD instruction set implemented by A32, T32 and A64)
- SVE (Scalable Vector Extensions) in A64 with vectors from 128 to 2048 bits wide.

The Architecture spec is approaching 9000 pages.

https://developer.arm.com/documentation/ddi0487/latest/

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 16:39:39 GMT

Post by Scott Lurndal
The Architecture spec is approaching 9000 pages.
https://developer.arm.com/documentation/ddi0487/latest/

When I think back to discussions on the most efficient way to clear
the screen on a 6502 it becomes clear that a beast like that is too complex
for anyone to be sure of the best way of doing things with it - but there
are sure to be plenty of options that are good enough.

[Thomas Koenig]

Post by Scott Lurndal
The Architecture spec is approaching 9000 pages.

Which is bordering on insane... who is going to read and implement
all this?

Post by Scott Lurndal
https://developer.arm.com/documentation/ddi0487/latest/

Nobody ever accused POWER of having few instructions, but even
the not-yet-implemented PowerISA 3.1 has "only" 1514 pages.

Plus, there is a POWER 3.0 implementation with a total of
26278 lines of VHDL. Can't be all that

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 20:21:21 -0000 (UTC)

Post by Thomas Koenig

Post by Scott Lurndal
The Architecture spec is approaching 9000 pages.

Which is bordering on insane... who is going to read and implement
all this?

Compiler writers, we hope. More seriously there is so much
diversity in there, much of it highly specialised, that it seems to me that
nobody needs to read it all, The SOC implementers simply(sic) have to
render the logic description into silicon. The compiler writers can focus
on specific aspects of it at a time while things like the cryptographic
support are only of direct interest to a few.

[Scott Lurndal]

Post by Thomas Koenig

Post by Scott Lurndal
The Architecture spec is approaching 9000 pages.

Which is bordering on insane... who is going to read and implement
all this?

That is literally my day job, to implement this specification
in a software simulator. We started in in 2012 when the spec
was only 5000 pages (we also designed and built several chips based on the
specification).

Post by Thomas Koenig

Post by Scott Lurndal
https://developer.arm.com/documentation/ddi0487/latest/

Nobody ever accused POWER of having few instructions, but even
the not-yet-implemented PowerISA 3.1 has "only" 1514 pages.

I didn't mention the 900 page interrupt controller specification,
the 400 page SMMU (I/O MMU) specification, the SVE (or SVE2)
instruction set specifications or the memory partitioning
specification, the embedded trace macrocell (ETM) specification
or the coresight specifications and a handful of others.

[Thomas Koenig]

Post by g***@gmail.com
They mentioned 2000
instructions!?!?

Depending on how you count, I guess... does a bit which specifies
if you optionally set the carry bit for an addition make this
a new instruction or not?

[Owen Rees]

On Thu, 22 Apr 2021 16:57:43 +0100, gareth evans

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?

LoongArch seems to be a possibly useful search term but the pages that
the links suggest are more detailed seem to be all in Chinese (which I
do not speak or read).

Post by gareth evans
(As always, real computer scientists program
in assembler :-) )

Real computer scientists write compilers in order to avoid having to
write in assembly language.

When a program I had written in C for a Motorola 68000 based machine was
not as fast as I wanted I did some work on the optimisation phase of the
compiler to make better use of the addressing modes rather than
rewriting any significant part in assembler. (There are 8 lines of
assembler - a function that makes a system call not available in the
runtime library that I got with the compiler.)

As is usually the case, time spent improving the data structures and
algorithms was far more useful that recoding in assembly language would
have been.

The more extreme computer scientists write binary translators so that
the processor with the new architecture can run code compiled (or
written in assembler) for a different architecture. Including binary
translation into the new processor architecture - presumably for
Just-In-Time translation - seems a bit crazy to me but the descriptions
I have seen suggest that LoongArch does that.

[Quadibloc]

Post by gareth evans
AIUI this is a new ISA that does not tread on the
patents of ARM, X86 and MIPS.
I've googled unsuccessfully so any pointers
to this ISA?

What I read about the Loongson 3A5000 is indeed that the ISA
is novel, not involving ISA from MIPS or Alpha, but it also mentioned
that this new ISA was only, for now, shared with select Loongsoon
business partners: it has _not_ yet been made public. So, unless there
is a leak, you won't find it on the Internet.

John Savard