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

gareth evans <headst...@yahoo.com> schrieb:

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

[Charlie Gibbs]

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

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[Scott Lurndal]

gareth evans <headst...@yahoo.com> writes:
>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

[Scott Lurndal]

Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
>On 2021-04-22, gareth evans <headst...@yahoo.com> wrote:
>
>> 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.

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

Been there, hence my comment about unsuccessful googling.

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

[gareth evans]

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]

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
gareth evans <headst...@yahoo.com> wrote:

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

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Owen Rees]

On Thu, 22 Apr 2021 16:57:43 +0100, gareth evans
<headst...@yahoo.com> wrote in <s5s6e6$2ae$1...@dont-email.me>:

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

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

[Dan Espen]

gree...@gmail.com writes:

> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
> <headst...@yahoo.com> sprachen:

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

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

--
Dan Espen

[Thomas Koenig]

Dan Espen <dan1...@gmail.com> schrieb:

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

[gareth evans]

On 22/04/2021 22:53, Ahem A Rivet's Shot wrote:
> On Thu, 22 Apr 2021 21:20:43 +0100
> gareth evans <headst...@yahoo.com> wrote:
>
>> 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.

[gareth evans]

On 23/04/2021 04:51, gree...@gmail.com wrote:
> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans <headst...@yahoo.com> sprachen:
>

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

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

[Peter Flass]

+1

--
Pete

[Peter Flass]

It gives you a cross-reference if register usage.

--
Pete

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

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.

--
Dan Espen

[Scott Lurndal]

Dan Espen <dan1...@gmail.com> writes:
>gree...@gmail.com writes:
>
>> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
>> <headst...@yahoo.com> sprachen:
>>
>>>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?
>>
>>>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.

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

[Scott Lurndal]

at the end of a paper listing, no doubt.

[Scott Lurndal]

gree...@gmail.com writes:
>On Thu, 22 Apr 2021 17:39:05 GMT, sc...@slp53.sl.home (Scott Lurndal) sprachen:

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

[Dan Espen]

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

--
Dan Espen

[Dan Espen]

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.

--
Dan Espen

[Dan Espen]

sc...@slp53.sl.home (Scott Lurndal) writes:

> Dan Espen <dan1...@gmail.com> writes:
>>gree...@gmail.com writes:
>>
>>> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
>>> <headst...@yahoo.com> sprachen:
>>>
>>>>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?
>>>
>>>>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.

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

--
Dan Espen

[Scott Lurndal]

Dan Espen <dan1...@gmail.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) writes:
>
>> Dan Espen <dan1...@gmail.com> writes:
>>>gree...@gmail.com writes:
>>>
>>>> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
>>>> <headst...@yahoo.com> sprachen:
>>>>
>>>>>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?
>>>>
>>>>>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.

[Johann 'Myrkraverk' Oskarsson]

On 23/04/2021 3:51 am, gree...@gmail.com wrote:
> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans <headst...@yahoo.com> sprachen:
>

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

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

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

[Peter Flass]

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

--
Pete

[Peter Flass]

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

--
Pete

[Thomas Koenig]

Peter Flass <peter...@yahoo.com> schrieb:

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

On 2021-04-22, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On Thu, 22 Apr 2021 21:20:43 +0100
> gareth evans <headst...@yahoo.com> wrote:
>
>> 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.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[Charlie Gibbs]

On 2021-04-23, Dan Espen <dan1...@gmail.com> wrote:

> gree...@gmail.com writes:
>
>> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
>> <headst...@yahoo.com> sprachen:
>>

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

[Charlie Gibbs]

On 2021-04-23, Dan Espen <dan1...@gmail.com> wrote:

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

[Charlie Gibbs]

On 2021-04-23, gree...@gmail.com <gree...@gmail.com> wrote:

> On Thu, 22 Apr 2021 21:20:43 +0100, gareth evans
> <headst...@yahoo.com> sprachen:
>

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

[Charlie Gibbs]

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.

[Quadibloc]

On Thursday, April 22, 2021 at 9:57:59 AM UTC-6, gareth evans wrote:
> 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

[Richard Thiebaud]

All programs have environment consideration.

[Niklas Karlsson]

On 2021-04-23, Johann 'Myrkraverk' Oskarsson <joh...@myrkraverk.invalid> wrote:
>
> 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
--
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

[Scott Lurndal]

Niklas Karlsson <nikke.k...@gmail.com> writes:
>On 2021-04-23, Johann 'Myrkraverk' Oskarsson <joh...@myrkraverk.invalid> wrote:
>>
>> 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]

On 24/04/2021 17:26, Scott Lurndal wrote:
> Niklas Karlsson <nikke.k...@gmail.com> writes:
>> On 2021-04-23, Johann 'Myrkraverk' Oskarsson <joh...@myrkraverk.invalid> wrote:
>>>
>>> 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]

On 2021-04-24, Scott Lurndal <sc...@slp53.sl.home> wrote:
> Niklas Karlsson <nikke.k...@gmail.com> writes:
>>

>>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
--
If infinite rednecks fired infinite shotguns at an infinite number of road
signs, they'd eventually create all the great literary works of the world in
braille. --Discordian Quote File

[gareth evans]

On 24/04/2021 22:42, gree...@gmail.com wrote:
> On Fri, 23 Apr 2021 14:33:09 +0100, gareth evans <headst...@yahoo.com> sprachen:
>
>> 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?

[Ahem A Rivet's Shot]

On Sat, 24 Apr 2021 16:26:37 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> [*] 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.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Peter Flass]

<gree...@gmail.com> wrote:
> On Fri, 23 Apr 2021 18:47:25 -0000 (UTC), Thomas Koenig <tko...@netcologne.de> sprachen:

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

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



--
Pete

[Peter Flass]

<gree...@gmail.com> wrote:
> On Fri, 23 Apr 2021 14:33:09 +0100, gareth evans <headst...@yahoo.com> sprachen:
>
>> 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.

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

[Peter Flass]

<gree...@gmail.com> wrote:
> On Sat, 24 Apr 2021 16:26:37 GMT, sc...@slp53.sl.home (Scott Lurndal) sprachen:

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

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

[Peter Flass]

<gree...@gmail.com> wrote:
> On 23 Apr 2021 20:30:07 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid> sprachen:

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

[Joy Beeson]

On Sat, 24 Apr 2021 21:33:35 GMT, gree...@gmail.com wrote:

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



--
Joy Beeson
joy beeson at centurylink dot net
http://wlweather.net/PAGEJOY/

[Ahem A Rivet's Shot]

On Sat, 24 Apr 2021 23:09:14 GMT
gree...@gmail.com wrote:

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

[Thomas Koenig]

Peter Flass <peter...@yahoo.com> schrieb:

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

> with all the plusses and minusses of that, but
> it comes with a lot of cruft.

The standard library is rather big now, yes.

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

On 24/04/2021 23:14, gree...@gmail.com wrote:
> On Sat, 24 Apr 2021 22:58:34 +0100, gareth evans <headst...@yahoo.com> sprachen:

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

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

[gareth evans]

On 25/04/2021 09:08, Thomas Koenig wrote:
> Peter Flass <peter...@yahoo.com> schrieb:
>
>> 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

[Niklas Karlsson]

On 2021-04-24, gree...@gmail.com <gree...@gmail.com> wrote:
>
> 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
--
> I still haven't found the right problem to learn perl over...
Your essential mistake here is that you seek such a program. This is
self-defeating Zen. When the time is right, the right program will quietly make
_itself_ known to you. -- Christian Bauernfeind and Tanuki in asr

[Niklas Karlsson]

On 2021-04-24, gree...@gmail.com <gree...@gmail.com> wrote:
>

> 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
--
Lithospheric flight paths typically result in extremely high drag
coefficients, often quite a bit in excess of design parameters.
-- Rick Dickinson

[anti...@math.uni.wroc.pl]

Peter Flass <peter...@yahoo.com> wrote:
> <gree...@gmail.com> wrote:
> > On Fri, 23 Apr 2021 14:33:09 +0100, gareth evans <headst...@yahoo.com> sprachen:
> >
> >> 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.

--
Waldek Hebisch

[Scott Lurndal]

gree...@gmail.com writes:
>On 23 Apr 2021 20:30:07 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid> sprachen:
>

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

[Scott Lurndal]

Peter Flass <peter...@yahoo.com> writes:
><gree...@gmail.com> wrote:
>> On Fri, 23 Apr 2021 14:33:09 +0100, gareth evans <headst...@yahoo.com> sprachen:
>>
>>> 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).

[Scott Lurndal]

Thomas Koenig <tko...@netcologne.de> writes:
>Peter Flass <peter...@yahoo.com> schrieb:
>
>> 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.

[Scott Lurndal]

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

[John Levine]

According to Scott Lurndal <sl...@pacbell.net>:

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

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Scott Lurndal]

gree...@gmail.com writes:
>On Fri, 23 Apr 2021 14:51:37 GMT, sc...@slp53.sl.home (Scott Lurndal) sprachen:
>
>>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/

[Charlie Gibbs]

On 2021-04-25, Thomas Koenig <tko...@netcologne.de> wrote:

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

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 08:08:40 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:

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

Print on the toast of course.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)
anti...@math.uni.wroc.pl wrote:

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

Ahem A Rivet's Shot <ste...@eircom.net> schrieb:

> On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)
> anti...@math.uni.wroc.pl wrote:
>
>> 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.

[Charlie Gibbs]

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

[anti...@math.uni.wroc.pl]

John Levine <jo...@taugh.com> wrote:
> According to Scott Lurndal <sl...@pacbell.net>:
> >>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.

--
Waldek Hebisch

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 16:39:39 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

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

[Ahem A Rivet's Shot]

On 25 Apr 2021 11:23:20 GMT

Niklas Karlsson <nikke.k...@gmail.com> wrote:

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

[Thomas Koenig]

John Levine <jo...@taugh.com> schrieb:

> According to Scott Lurndal <sl...@pacbell.net>:
>>>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.

[Thomas Koenig]

gree...@gmail.com <gree...@gmail.com> schrieb:
> 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?

[Thomas Koenig]

Scott Lurndal <sc...@slp53.sl.home> schrieb:

> The Architecture spec is approaching 9000 pages.

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

> 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 18:08:00 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:

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

[Vir Campestris]

On 24/04/2021 22:42, gree...@gmail.com wrote:
> 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

[Owen Rees]

On Sun, 25 Apr 2021 21:05:08 +0100, Ahem A Rivet's Shot
<ste...@eircom.net> wrote in
<20210425210508.f013...@eircom.net>:

>On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)
>Thomas Koenig <tko...@netcologne.de> wrote:
>
>> 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.

[Thomas Koenig]

Ahem A Rivet's Shot <ste...@eircom.net> schrieb:

> On Sun, 25 Apr 2021 18:08:00 -0000 (UTC)
> Thomas Koenig <tko...@netcologne.de> wrote:
>
>> 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...

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 20:21:21 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:

> Scott Lurndal <sc...@slp53.sl.home> schrieb:
>
> > 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.

[Ahem A Rivet's Shot]

On Sun, 25 Apr 2021 20:01:03 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:

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

[gareth evans]

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]

John Levine <jo...@taugh.com> writes:
>According to Scott Lurndal <sl...@pacbell.net>:
>>>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).

[Scott Lurndal]

Thomas Koenig <tko...@netcologne.de> writes:
>Scott Lurndal <sc...@slp53.sl.home> schrieb:
>
>> 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).

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

[Scott Lurndal]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On 25 Apr 2021 11:23:20 GMT
>Niklas Karlsson <nikke.k...@gmail.com> wrote:
>
>> 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.

[Scott Lurndal]

gareth evans <headst...@yahoo.com> writes:
>On 25/04/2021 21:36, Vir Campestris wrote:
>> On 24/04/2021 22:42, gree...@gmail.com wrote:
>>> 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.

[Peter Flass]

<gree...@gmail.com> wrote:
> On Sat, 24 Apr 2021 15:45:16 -0700, Peter Flass <peter...@yahoo.com> sprachen:

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

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



--
Pete

[Peter Flass]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> gree...@gmail.com writes:
>> On 23 Apr 2021 20:30:07 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid> sprachen:
>>
>>> 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.

--
Pete

[Peter Flass]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Sun, 25 Apr 2021 12:24:21 +0000 (UTC)
> anti...@math.uni.wroc.pl wrote:
>
>> 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.

--
Pete

[Peter Flass]

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.

--
Pete

[Scott Lurndal]

Peter Flass <peter...@yahoo.com> writes:
><gree...@gmail.com> wrote:
>> On Sat, 24 Apr 2021 15:45:16 -0700, Peter Flass <peter...@yahoo.com> sprachen:
>>
>>> 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.

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

[Scott Lurndal]

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

[Scott Lurndal]

IME, it's more important to optimize for the hardware that the
program is being run on; for portable applications, let the compiler
do it for each target architecture.

Modern optimizations techniques are quite advanced. They do
make the resulting object code more complicated for the Human
to understand.

[Dennis Boone]

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

Seems like a good place to drop a link to this:

https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

for those who might want to try the concept.

De

[Ahem A Rivet's Shot]

On Tue, 27 Apr 2021 14:04:54 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

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

At Inelegant^WIntelligent Software I used a C compiler on one of
CP/M-86 or MSDOS (the machine ran both - I think the compiler was for
CP/M-86 BICBW) it was a stripped down C (no bit field in structs for a
start) but it worked. I used it to build a remote debugging/development tool
for games consoles (dummy cartridge with RAM, bootstrap ROM and RS232 to
computer - we got pretty slick at knocking them up for various consoles).
The assembler and disassembler were processor agnostic with tables defining
the ISA). Meanwhile Nick Toop was upstairs working on the Elan Enterprise
design.

[Peter Flass]

Interesting, but this is saving bytes on disk, not all of which usually
make it into memory anyway.

--
Pete

[Dennis Boone]

> Interesting, but this is saving bytes on disk, not all of which usually
> make it into memory anyway.

I think you've missed the point. Before he gets off into the weeds of
re-using parts of the ELF header etc to save bytes, he demonstrates
what's needed to build executables with the gcc toolchain that don't
drag in the standard crt0 and library bits.

De

[Owen Rees]

On Mon, 26 Apr 2021 15:53:54 -0700, Peter Flass <peter...@yahoo.com>
wrote in
<601946560.641169448.7265...@news.eternal-september.org>:

Except that code continues to be used a lot longer than the original
writer expects both for its original purpose and copied and pasted into
some other context where the assumptions made by the original programmer
no longer apply. The more effort it takes to write new code, the
stronger the temptation to take something that works and use it
elsewhere where it works for the simple cases but fails in obscure ways
with data that would never have arisen in its original context.

Assembler is at the expensive and time consuming to write end of the
range so the temptation to take chunks of code and use them elsewhere is
at its worst.

I would use assembler in places where I cannot avoid it but not
otherwise. Except of course if I am doing it just for fun rather than
because I want to create a program for some purpose.

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

IIRC there was a proposed language called NewSpeak where every variable
had to be declared as a range. The type system turned out to be very
difficult for those trying to write the compiler and impossible for
those trying to write programs in it.

[Peter Flass]

Thanks, I skimmed it, but saved a link to review later. When I’m talking
about C on a PC, my first compiler was “Aztec C”, which was pretty basic
with no overhead. Then I used Borland Turbo-C. I think I used VAX C at one
point, and only a bit of Gcc for Linux.

--
Pete

[gareth evans]

I had Zorland C for the 16 bit DOS world.

I think that they were trying to parasitise off the Borland name!

[greymaus]

I remember Lattice C which also carried my First virus, then there was
Dice C, I think, which was, I think, slightly abberant, but really
worked. After that, it was interpeters all the way.

[Ahem A Rivet's Shot]

On Wed, 28 Apr 2021 15:40:35 -0700
Peter Flass <peter...@yahoo.com> wrote:

> and only a bit of Gcc for Linux

Oh dear, gcc is somewhat older than Linux (it came out in 1987),
for some years it was popular in many unix houses because it ran on all the
myriad variants of unix you could find and made porting applications a
*lot* easier when at least the compiler was consistent.

I had my copies of the GNU and X11 tapes about the time Linux was
starting to turn into an OS (I got X11R5 when it was very new). They weren't
easy to get and the X11 tape was even less easy to compile and get running.

[Andy Leighton]

Borland started with Turbo C in 1987. Zortech released Zorland C about
a year before that. At the time of release Borland were really only
known for Turbo Pascal and Sidekick so it seems a strange hill to make
a stand on.

Zortech was a British company.

I started with C on 4.2BSD running on a Vax at college but then when I
got a job it was Lattice-C on Wndows. At home I had a year or two with
Turbo C before I moved to a Linux machine.

--
Andy Leighton => an...@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams

[Scott Lurndal]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Wed, 28 Apr 2021 15:40:35 -0700
>Peter Flass <peter...@yahoo.com> wrote:
>
>> and only a bit of Gcc for Linux
>
> Oh dear, gcc is somewhat older than Linux (it came out in 1987),
>for some years it was popular in many unix houses because it ran on all the
>myriad variants of unix you could find and made porting applications a
>*lot* easier when at least the compiler was consistent.
>
> I had my copies of the GNU and X11 tapes about the time Linux was
>starting to turn into an OS (I got X11R5 when it was very new). They weren't
>easy to get and the X11 tape was even less easy to compile and get running.

I've still got the X11R3 QIC tape and a 9-track GCC tape that we ordered
from the FSF circa 1989/1990.

GCC, at the time, was inferior to the native SVR4 SGS C compiler, although
it was better than the PCC compiler we were using with the Motorola 88100.

[Ahem A Rivet's Shot]

On Thu, 29 Apr 2021 16:52:09 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> GCC, at the time, was inferior to the native SVR4 SGS C compiler, although
> it was better than the PCC compiler we were using with the Motorola 88100.

From our point of view (more than one our) the quality
considerations were overridden by being able to have the same compiler for
all the ports.