From Newsgroup: comp.compilers

//Hello all,//

Hi,

I have started to learn Assembler out of an old book.

It is ancient (2003) but I don't think 8086 programming has changed
much. But the tools have.

I took assembly language in school but dropped out. Now I want another
go at it.

Would someone be my Mentor and answer a ton of questions that would
dwindle out as time went on?

If it's OK, we could do it here. Or netmail

Books are from a bookstore.


Book 1
Assembly Language for the PC 3rd edition, John Socha and Peter Norton.

Book 2
Assembly Language (step by step) Jeff Duntemann. Too Chatty.

I cannot afford a modern book at this time.

Thats what I picked up from the thrift store.

These books are dated around the time I was taking machine code in
school and I find it interesting now.

I hope someone picks me up.

I am running linux and using DOSemu

Also a modern DEBUG and and a modern Vi

I am also a Ham Radio Operator (45 years)

1:229/426.36

Regards,
Alan Beck
VY2XU
[Please reply directly unless the response is relatted to compilers. -John]



--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Tuesday, March 21, 2023 at 2:40:22rC>PM UTC-7, Alan Beck wrote:

I have started to learn Assembler out of an old book.

(Hopefully enough related to compilers.)

Not so long after I started learning OS/360 Fortran and PL/I, I found
the compiler option for printing out the generated code in sort-of
assembly language. (Not actually assembleable, though.)

About that time, I also had source listings on microfilm of
the OS/360 Fortran library, and some other Fortran callable
assembly programs. And also, the IBM S/370 Principles
of Operation.

With those, and no actual book meant to teach assembly
programming, I figured it out, and started writing my own
programs, though mostly callable from Fortran or PL/I.

Compilers today don't write out the generated code in the same way,
and there aren't so many libraries around to read. And, personally,
8086 is my least favorite to write assembly code in.

Learning C, and thinking about pointers and addresses, is a good start
toward assembly programming.

In any case, I don't think I have any idea how others learn
programming for any language, and especially not for assembly
programming. I used to read IBM reference manuals, cover to cover.
That was mostly high school years. After that, I figured out how to
use them as reference manuals.

Most of my 80x86 assembly programming in the last
20 years is (re)writing this one program:

rdtsc: rdtsc
ret

When called from C, and returning a 64 bit integer, it return the Time
Stamp Counter. (Works for 32 bit code, returning in EDX:EAX. 64 bit is different.)

C programming works so well, that there are only a few
things you can't do in C, and so need assembly programs.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

gah4 <gah4@u.washington.edu> schrieb:

On Tuesday, March 21, 2023 at 2:40:22rC>PM UTC-7, Alan Beck wrote:

I have started to learn Assembler out of an old book.

At the risk of stating the blindingly obvious: There is more
than one assembler language, each computer architecture has its
own (with extensions over time, too). There are also sometimes
different syntax variant, for example AT&T vs. Intel.

[...]

Compilers today don't write out the generated code in the same way,

Quite the opposite.

The standard on UNIXy systems is to write out assemblly language to
a file, which is then further processed with the actual assembler.
Use "-S" to just generate the foo.s file from foo.c.

Plus, you can disassemble object files and programs with "objdump -d".

and there aren't so many libraries around to read.

Not ones written in assembler. But it is possible to download
the source code to many libraries, for example glibc, and then
examine what it is compiled to.

Another possibility would be to use http://godbolt.org, which shows
you assembler generated for different systems with differnt options.
To really make sense of it for different architectures you are
not familiar with may be difficult, though). Or build clang/LLVM
yourself and set different options for the architecture.

And, personally,
8086 is my least favorite to write assembly code in.

I like 6502 even less :-)

Learning C, and thinking about pointers and addresses, is a good start
toward assembly programming.

That, I agree with. And it helps a lot to also look at the
generated code.

[...]

C programming works so well, that there are only a few
things you can't do in C, and so need assembly programs.

Bringing it back a bit towards compilers: Reading assembler code is
a good way to see where they generate inefficient or (more rarely)
incorrect code. In some special cases, writing in assembler can
bring benefits of a factor of 2 or even 4 over compiler-generated
code, usually when SIMD is involved.

Assembler is a bit like Latin: For most people, there is no need
to speak or write, but one should be able to read it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

gah4 <gah4@u.washington.edu> writes:

Not so long after I started learning OS/360 Fortran and PL/I, I found
the compiler option for printing out the generated code in sort-of
assembly language. (Not actually assembleable, though.)

...

Compilers today don't write out the generated code in the same way,

Unix (Linux) compilers like gcc usually write assembly-language code
if you use the option -S. This code can be assembled, because AFAIK
that's the way these compilers produce object code.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On 21/03/2023 22:40, Alan Beck wrote:

//Hello all,//

Hi,

I have started to learn Assembler out of an old book.

It is ancient (2003) but I don't think 8086 programming has changed
much. But the tools have.

I took assembly language in school but dropped out. Now I want another
go at it.

Would someone be my Mentor and answer a ton of questions that would
dwindle out as time went on?

If it's OK, we could do it here. Or netmail

Books are from a bookstore.

I have both these books on my bookshelf - but it was a /long/ time ago
that I read them.

The big question here is /why/ you are doing this. The 8086 is ancient
history - totally irrelevant for a couple of decades at least. Modern
PC's use x86-64, which is a very different thing. You don't learn
modern Spanish by reading an old Latin grammar book, even though
Spanish is a Latin language.

There are, perhaps, four main reasons for being interested in learning
to write assembly:

1. You need some very niche parts of a program or library to run as
fast as feasible. Then you want to study the details of your target
processor (it won't be an 8086) and its instruction set - typically
focusing on SIMD and caching. Done well, this can lead to an order of
magnitude improvement for very specific tasks - done badly, your
results will be a lot worse than you'd get from a good compiler with
the right options. The "comp.arch" newsgroup is your first point of
call on Usenet for this.

2. You need some very low-level code for things that can't be
expressed in a compiled language, such as task switching in an OS.
Again, you need to focus on the right target. "comp.arch" could be a
good starting point here too.

3. You are working on a compiler. This requires a deep understanding of
the target processor, but you've come to the right newsgroup.

4. You are doing this for fun (the best reason for doing anything) and learning. You can come a long way with getting familiar with
understanding (but not writing) assembly from looking at the output of
your favourite compilers for your favourite targets and favourite
programming languages on <https://godbolt.org>. Here I would pick an
assembly that is simple and pleasant - 8086 is neither.

I would recommend starting small, such as the AVR microcontroller
family. The instruction set is limited, but fairly consistent and easy
to understand. There is vast amounts of learning resources in the
Arduino community (though most Arduino development is in C or C++), and
you can buy an Arduino kit cheaply. Here you can write assembly code
that actually does something, and the processor ISA is small enough that
you can learn it /all/.


If none of that covers your motivation, then give some more details of
what you want to achieve, and you can probably get better help.
(comp.arch might be better than comp.compilers if you are not interested
in compilers.)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Tue, 21 Mar 2023 17:40:18 -0400 (EDT), Alan.Beck@darkrealms.ca
(Alan Beck) wrote:

... I don't think 8086 programming has changed
much. But the tools have. ...
Would someone be my Mentor and answer a ton of questions that would
dwindle out as time went on?

Assembler mostly is off-topic here in comp.compilers, but
comp.lang.asm.x86 will be open to pretty much any question regarding
80x86 assembler.

[Please reply directly unless the response is related to compilers. -John]

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Wednesday, March 22, 2023 at 12:06:05rC>PM UTC-7, Thomas Koenig wrote:

gah4 <ga...@u.washington.edu> schrieb:

(snip)

Compilers today don't write out the generated code in the same way,

Quite the opposite.

The standard on UNIXy systems is to write out assemblly language to
a file, which is then further processed with the actual assembler.

Yes, not the same way.

Well, to be sure that this is about compilers, my favorite complaint
is the lost art of small memory compilers. That is, ones that can
run in kilobytes instead of megabytes.

In any case, the OS/360 compilers don't write out assembly code
that an assembler would recognize. It is meant for people.

Some write it out in two columns to save paper.
Labels don't have to agree with what assemblers recognize.
They don't have to be in the same order that they would be for
an assembler, though OS/360 object programs don't have to be
in order, either.

Having not thought about this for a while, I believe they put
in some comments that help human readers, though likely not
what an assembly programmer would say.

Unixy systems might put in some comments, but mostly don't.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Friday, March 24, 2023 at 7:10:00rC>AM UTC-7, Thomas Koenig wrote:

(snip about the lost art of small memory compilers.)

On the Internet, there is a project for almost everything - in this
case Tiny C, which still seems to be under active development. Or
at least there are sill commits at https://repo.or.cz/w/tinycc.git .

However, there is a reason why compilers got so big - there is
always a balance to be struck between comilation speed, compiler
size and optimization.

When I was writing the above, I was looking at the Program Logic
Manual for the OS/360 Fortran G compiler.
(G means it is supposed to run in 128K.)

Fortran G was not written by IBM, but contracted out. And is not
(mostly) in assembler, but in something called POP. That is, it
is interpreted by the POP interpreter, with POPcode written using
assembler macros. Doing that, for one, allows reusing the code
for other machines, though you still need to rewrite the code
generator. But also, at least likely, it decreases the size of
the compiler. POP instructions are optimized for things that
compiler need to do.

I also had the source to that so many years ago, but not the
manual describing it.

An extreme example: According to "Abstracting Away the Machine", the
very first FORTRAN compiler was so slow that the size of programs
it could compile was limited by the MTBF of the IBM 704 of around
eight hours.

I remember stories about how well its optimizer worked, when
it was believed that they had to compete in code speed with
experienced assembly programmers. I don't remember anything
about how fast it was.

The balance has shifted over time, because of increasing computing
power and available memory that can be applied to compilation,
and because relatively more people use programs than use compilers
than ever before. So, in today's environment, there is little
incentive for writing small compilers.

I first thought about this, when reading about the Hercules project
of an IBM S/370 emulator, and couldn't run gcc in 16MB.
(Well, subtract some for the OS, but it still wouldn't fit.)

Also, languages have become bigger, more expressive, more powerful,
more bloated (take your pick), which also increases the size
of compilers.

OK, the IBM PL/I (F) compiler, for what many consider a bloated
language, is designed to run (maybe not well) in 64K.
At the end of every compilation it tells how much memory was
used, how much available, and how much to keep the symbol table
in memory.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On 3/24/23 10:17 PM, gah4 wrote:

Fortran G was not written by IBM, but contracted out. And is not
(mostly) in assembler, but in something called POP. That is, it
is interpreted by the POP interpreter, with POPcode written using
assembler macros. Doing that, for one, allows reusing the code
for other machines, though you still need to rewrite the code
generator. But also, at least likely, it decreases the size of
the compiler. POP instructions are optimized for things that
compiler need to do.

After a look at "open software" I was astonished by the number of
languages and steps involved in writing portable C code. Also updates of popular programs (Firefox...) are delayed by months on some platforms,
IMO due to missing manpower on the target systems for checks and the
adaptation of "configure". Now I understand why many people prefer
interpreted languages (Java, JavaScript, Python, .NET...) for a
simplification of their software products and spreading.

What's the actual ranking of programming languages? A JetBrains study
does not list any compiled language in their first 7 ranks in 2022. C++
follows on rank 8.

What does that trend mean to a compiler group? Interpreted languages
still need a front-end (parser) and back-end (interpreter), but don't
these tasks differ between languages compiled to hardware or interpretation?

DoDi
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Sat, 25 Mar 2023 13:07:57 +0100, Hans-Peter Diettrich <DrDiettrich1@netscape.net> wrote:

After a look at "open software" I was astonished by the number of
languages and steps involved in writing portable C code. Also updates of >popular programs (Firefox...) are delayed by months on some platforms,
IMO due to missing manpower on the target systems for checks and the >adaptation of "configure". Now I understand why many people prefer >interpreted languages (Java, JavaScript, Python, .NET...) for a >simplification of their software products and spreading.

Actually Python is the /only/ one of those that normally is
interpreted. And the interpreter is so slow the language would be
unusable were it not for the fact that all of its standard library
functions and most of its useful extensions are written in C.

In practice Java and Javascript almost always are JIT compiled to
native code rather than interpreted. There also exist offline (AOT)
compilers for both.

Many JIT runtimes do let you choose to have programs interpreted
rather than compiled, but running interpreted reduces performance so
much that it is rarely done unless memory is very tight.


.NET is not a language itself but rather a runtime system like the
Jave Platform. .NET consists of a virtual machine: the Common
Language Runtime (CLR); and a set of standard libraries. Similarly
the Java Platform consists of a virtual machine: the Java Virtual
Machine (JVM); and a set of standard libraries. Compilers target
these runtime systems.

The .NET CLR does not include an interpreter ... I'm not aware that
there even is one for .NET. There is an offline (AOT) compiler that
can be used instead of the JIT.

What's the actual ranking of programming languages? A JetBrains study
does not list any compiled language in their first 7 ranks in 2022. C++ >follows on rank 8.

What does that trend mean to a compiler group? Interpreted languages
still need a front-end (parser) and back-end (interpreter), but don't
these tasks differ between languages compiled to hardware or interpretation?

The trend is toward "managed" environments which offer niceties like
GC, objects with automagic serialized access, etc., all to help
protect average programmers from themselves ... err, um, from being
unable to produce working software.

DoDi

George

--- Synchronet 3.21b-Linux NewsLink 1.2