Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3403 > unrolled thread

fledgling assembler programmer

Back to article view | Back to comp.compilers

Contents

  fledgling assembler programmer Alan.Beck@darkrealms.ca (Alan Beck) - 2023-03-21 17:40 -0400
    Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-21 17:23 -0700
      Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-22 06:49 +0000
        Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-22 13:31 -0700
          Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-23 11:26 +0000
            Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 14:17 -0700
              Re: ancient PL/I, was fledgling assembler programmer drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-24 22:51 +0000
                Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 22:44 -0700
                  Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-25 01:27 -0700
              Re: fledgling assembler programmer Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-25 13:07 +0100
                Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-25 20:54 -0400
                  Portable Software (was: fledgling assembler programmer) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-28 09:21 +0200
                    Re: Portable Software (was: fledgling assembler programmer) arnold@freefriends.org (Aharon Robbins) - 2023-03-28 14:42 +0000
                      Re: configuguration tools, Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:33 +0000
                        Re: configuguration tools, Portable Software (was: fledgling assembler programmer) arnold@skeeve.com (Aharon Robbins) - 2023-03-31 07:10 +0000
                        Re: configuguration tools, Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 08:56 +0000
                      Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-31 07:49 +0200
                        Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 10:04 +0000
                          Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-05 11:23 +0200
                            Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-05 16:30 +0000
                              Re: Portable Software Kaz Kylheku <864-117-4973@kylheku.com> - 2023-04-06 08:35 +0000
                              Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-07 15:35 +0200
                              Re: Portable Software Thomas Koenig <tkoenig@netcologne.de> - 2023-04-08 18:25 +0000
                    Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-28 14:21 -0700
                      Re: Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:34 +0000
                    Re: Portable Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-28 17:26 -0400
                      Re: Portable python Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-29 13:50 -0400
                      Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-29 11:27 -0700
                        Re: Portable Software (was: fledgling assembler programmer) Thomas Koenig <tkoenig@netcologne.de> - 2023-03-31 05:19 +0000
                          Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-31 12:41 -0700
                    Re: Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-31 16:34 +0000
        Re: fledgling assembler programmer arnold@skeeve.com (Aharon Robbins) - 2023-03-23 13:56 +0000
      Re: fledgling assembler programmer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-22 10:02 +0000
    Re: fledgling assembler programmer David Brown <david.brown@hesbynett.no> - 2023-03-22 14:39 +0100
    Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-22 14:54 -0400

Page 2 of 2 — ← Prev page 1 [2]

#3450 — Re: Portable Software

On 2023-04-05, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
>>On 4/2/23 12:04 PM, Anton Ertl wrote:
>>
>>> For a Unix, there were a few hoops we had to jump through to make
>>> Gforth work: e.g., IRIX 6.5 had a bug in sigaltstack, so we put in a
>>> workaround for that; HP/UX's make dealt with files with the same mtime
>>> differently from other makes, so we put in a workaround for that.
>>> Windows, even with Cygwin, puts up many more hoops to jump through;
>>> Bernd Paysan actually jumped through them for Gforth, but a Windows
>>> build is still quite a bit of work, so he does that only occasionally.
>>
>>Too bad that not all existing OS are POSIX compatible? ;-)
>
> Like many standards, POSIX is a subset of the functionality that
> programs use.  Windows NT used to have a POSIX subsystem in order to
> make WNT comply with FIPS 151-2 needed to make WNT eligible for
> certain USA government purchases.  From what I read, it was useful for
> that, but not much else.

The best POSIX subsystem for Windows is arguably Cygwin. It has
quite a rich POSIX functionality. Not only that, but ANSI terminal
functionality: its I/O system contains a layer which translates
ANSI escape sequences into Windows Console API calls.

Yuo can take a program written on Linux which uses termios to put the
TTY in raw mode, and ANSI escapes to control the screen, and it will
work on Cygwin.

One of its downsides downside is that Cygwin has poor performance
(mainly in the area of file access).

The other downside of Cygwin is that it implements certain conventions
that are at odds with "native" Windows.

In 2016 I started a small project called Cygnal (Cygwin Native
Application Library) to fix problems in this second category,
creating a fork of the Cygwin DLL.

https://www.kylheku.com/cygnal

>>(G)FORTH IMO is a special case because it's (also) a development system.
>>Building (bootstrapping) a new FORTH system written in FORTH is quite
>>complicated, in contrast to languages with stand alone tools like
>>compiler, linker etc.
>
> Not really.  Most self-respecting languages have their compiler(s)
> implemented in the language itself, resulting in having to bootstrap.

You can avoid the chicken-and-egg problem that requires boostrapping by
using a host language to implement an interpreter for the target
language. That interpreter can then directly execute the compiler, which
can compile itself and other parts of the run-time, as needed.

It's still a kind of boostrapping, but at no point do you need a
pre-built binary of the target language compiler to build that compiler;
you just need an implementation of a host language.

This works quite well when the host language is good for writing
interpreters, and the target one for compiler work, and also when it's
useful to have an interpreter even when compilation is available.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#3451 — Re: Portable Software

On 4/5/23 6:30 PM, Anton Ertl wrote:
> Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:

> You mean: Write your program in Java, Python, Gforth, or the like?
> Sure, they deal with compatibility problems for you, but you may want
> to do things (or have performance) that they do not offer, or only
> offer through a C interface (and in the latter case you run into the
> C-level compatibility again).

Except the library also is portable ;-)

Else you end up with:
   Program runs only on systems with libraries X, Y, Z installed.


>> (G)FORTH IMO is a special case because it's (also) a development system.
>> Building (bootstrapping) a new FORTH system written in FORTH is quite
>> complicated, in contrast to languages with stand alone tools like
>> compiler, linker etc.
>
> Not really.  Most self-respecting languages have their compiler(s)
> implemented in the language itself, resulting in having to bootstrap.

The FORTH compiler also is part of the current monolithic framework.
Replacing a WORD has immediate impact on the just running compiler and
everything else. A bug can make the current system crash immediately,
without diagnostics. Else the current WORDs can not be replaced
immediately, only after a full compilation and only by code that depends
on neither the old nor the new framrwork.


> AFAIK the problem Gforth has with Windows is not the bootstrapping;
> packaging and installation are different than for Unix.

Isn't that the same problem with every language?

DoDi

[toc] | [prev] | [next] | [standalone]

#3452 — Re: Portable Software

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Most self-respecting languages have their compiler(s)
> implemented in the language itself, resulting in having to bootstrap.

This is a bit complicated for GCC and LLVM.

For both, the middle end (and back end) is implemented in C++,
so a C++ interface at class level is required, and that is a
bit daunting.

Examples: Gnat (GCC's Ada front end) is written in Ada, and its
Modula-2 front end is written in Modula-2.  On the other hand,
the Fortran front end is written in C++ (well, mostly C with
C++ features hidden behind macros).

The very first Fortran compiler, of course, was written in
assembler.
[It was, but Fortran H, the 1960s optimizing compiler for S/360 was
written in Fortran with a few data structure extensions. -John]

[toc] | [prev] | [next] | [standalone]

#3434 — Re: Portable Software (was: fledgling assembler programmer)

On Tuesday, March 28, 2023 at 1:14:29 AM UTC-7, Hans-Peter Diettrich wrote:

(snip)
> Then, from the compiler writer viewpoint, it's not sufficient to define
> a new language and a compiler for it, instead it must placed on top of
> some popular "firmware" like Java VM, CLR or C/C++ standard libraries,
> or else a dedicated back-end and libraries have to be implemented on
> each supported platform.

From an announcement today here on an ACM organized conference:


    "We encourage authors to prepare their artifacts for submission
     and make them more portable, reusable and customizable using
     open-source frameworks including Docker, OCCAM, reprozip,
     CodeOcean and CK."

I hadn't heard about those until I read that one, but it does sound
interesting.

[toc] | [prev] | [next] | [standalone]

#3439 — Re: Portable Software (was: fledgling assembler programmer)

On 2023-03-28, gah4 <gah4@u.washington.edu> wrote:
> On Tuesday, March 28, 2023 at 1:14:29 AM UTC-7, Hans-Peter Diettrich wrote:
>
> (snip)
>> Then, from the compiler writer viewpoint, it's not sufficient to define
>> a new language and a compiler for it, instead it must placed on top of
>> some popular "firmware" like Java VM, CLR or C/C++ standard libraries,
>> or else a dedicated back-end and libraries have to be implemented on
>> each supported platform.
>
> From an announcement today here on an ACM organized conference:
>
>
>     "We encourage authors to prepare their artifacts for submission
>      and make them more portable, reusable and customizable using
>      open-source frameworks including Docker, OCCAM, reprozip,
>      CodeOcean and CK."

"We encourage authors to lock their software to third party boat
anchors, such as ..."


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[If you are telling people not to use Docker, that whale sailed a long time ago. -John]

[toc] | [prev] | [next] | [standalone]

#3435 — Re: Portable Software (was: fledgling assembler programmer)

On Tue, 28 Mar 2023 09:21:50 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:

>On 3/26/23 1:54 AM, George Neuner wrote:
>> 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.
>
>My impression of "interpretation" was aimed at the back-end, where
>tokenized (virtual machine...) code has to be brought to a physical
>machine, with a specific firmware (OS). Then the real back-end has to
>reside on the target machine and OS, fully detached from the preceding
>compiler stages.

That is exactly as I meant it.

Python and Java both initially are compiled to bytecode.  But at
runtime Python bytecode is interpreted: the Python VM examines each
bytecode instruction, one by one, and executes an associated native
code subroutine that implements that operation.

In contrast, at runtime Java bytecode is JIT compiled to equivalent
native code - which include calls to native subroutines to implement
complex operations like "new", etc.  The JVM JIT compiles function by
function as the program executes ... so it takes some time before the
whole program exists as native code ... but once a whole load module
has been JIT compiled, the JVM can completely ignore and even unload
the bytecode from memory.


>Then, from the compiler writer viewpoint, it's not sufficient to define
>a new language and a compiler for it, instead it must placed on top of
>some popular "firmware" like Java VM, CLR or C/C++ standard libraries,
>or else a dedicated back-end and libraries have to be implemented on
>each supported platform.

Actually it simplifies the compiler writer's job because the
instruction set for the platform VM tends not to change much over
time.  A compiler targeting the VM doesn't have to scramble to support
features of every new CPU - in many cases that can be left to the
platform's JIT compiler.


>My impression was that the FSF favors C and ./configure for "portable"
>code. That's why I understand that any other way is easier for the
>implementation of really portable software, that deserves no extra
>tweaks for each supported target platform, for every single program. Can
>somebody shed some light on the current practice of writing portable
>C/C++ software, or any other compiled language, that (hopefully) does
>not require additional human work before or after compilation for a
>specific target platform?

Right. When you work on a popular "managed" platform (e.g., JVM or
CLR), then its JIT compiler and CPU specific libraries gain you any
CPU specific optimizations that may be available, essentially for
free.

OTOH, when you work in C (or other independent language), to gain CPU
specific optimizations you have to write model specific code and/or
obtain model specific libraries, you have to maintain different
versions of your compiled executables (and maybe also your sources),
and you need to be able to identify the CPU so as to install or use
model specific code.


For most developers, targeting a managed platform tends to reduce the
effort needed to achieve an equivalent result.


>DoDi
George
[The usual python implementation interprets bytecodes, but there are
also versions for .NET, the Java VM, and a JIT compiler. -John]

[toc] | [prev] | [next] | [standalone]

#3436 — Re: Portable python Software (was: fledgling assembler programmer)

>[The usual python implementation interprets bytecodes, but there are
>also versions for .NET, the Java VM, and a JIT compiler. -John]

Thanks John.  I knew about the reference implementation, but I was not
aware of the others.
George

[toc] | [prev] | [next] | [standalone]

#3437 — Re: Portable Software (was: fledgling assembler programmer)

On Wednesday, March 29, 2023 at 1:52:41 AM UTC-7, George Neuner wrote:

> Right. When you work on a popular "managed" platform (e.g., JVM or
> CLR), then its JIT compiler and CPU specific libraries gain you any
> CPU specific optimizations that may be available, essentially for
> free.

For system like Matlab and Octave, and I believe also for Python,
or one of many higher math languages, programs should spend
most of the time in the internal compiled library routines.

You could write a whole matrix inversion algorithm in Matlab
or Python, but no reason to do that.  That is the convenience
of matrix operations, and gets better as they get bigger.

In earlier days, there were Linpack and Eispack, and other
Fortran callable math libraries.  And one could write a
small Fortran program to call them.

But now we have so many different (more or less) interpreted
math oriented languages, that it is hard to keep track of them,
and hard to know which one to use.

[toc] | [prev] | [next] | [standalone]

#3441 — Re: Portable Software (was: fledgling assembler programmer)

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

> For system like Matlab and Octave, and I believe also for Python,
> or one of many higher math languages, programs should spend
> most of the time in the internal compiled library routines.

They should, but sometimes they don't.

If you run into things not covered by compiled libraries, but which
are compute-intensive, then Matlab and (interpreted) Python run
as slow as molasses, orders of magnitude slower than compiled code.

As far as the projects to create compiled versions with Python
go, one of the problems is that Python is a constantly evolving
target, which can lead to real problems, especially in long-term
program maintenance.  As Konrad Hinsen reported, results in
published science papers have changed due to changes in the Python
infrastructure:

http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/

At the company I work for, I'm told each Python project will only
use a certain specified version of Python will never be changed for
fear of incompatibilities - they treat each version as a new
programming language :-|

To bring this back a bit towards compilers - a language definition
is an integral part of compiler writing.  If

- the specification to o be implemented is unclear or "whatever
  the reference implementation does"

- the compiler writers always reserve the right for a better,
  incompatible idea

- the compiler writers do not pay careful attention to
  existing specifications

then the resuling compiler will be of poor quality, regardless of
the cool parsing or code generation that go into it.

And I know very well that reading and understanding language
standards is no fun, but I'm told that writing them is even
less fun.

[toc] | [prev] | [next] | [standalone]

#3445 — Re: Portable Software (was: fledgling assembler programmer)

On Friday, March 31, 2023 at 4:42:14 AM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:
> > For system like Matlab and Octave, and I believe also for Python,
> > or one of many higher math languages, programs should spend
> > most of the time in the internal compiled library routines.

> They should, but sometimes they don't.

> If you run into things not covered by compiled libraries, but which
> are compute-intensive, then Matlab and (interpreted) Python run
> as slow as molasses, orders of magnitude slower than compiled code.

But then there is dynamic linking.

I have done it in R, but I believe it also works for Matlab and
Python, and is the way many packages are implemented. You write a
small C or Fortran program that does the slow part, and call it from
interpreted code.

And back to my favorite x86 assembler program:

rdtsc: rdtsc
   ret

which allows high resolution timing, to find where the program
is spending too much time.  Some years ago, I did this on a program
written by someone else, so I mostly didn't know the structure.
Track down which subroutines used too much time, and fix
just those.

In that case, one big time sink is building up a large matrix one
row or one column at a time, which requires a new allocation and
copy for each time.  Preallocating to the final (if known) size fixes that.

But then there were some very simple operations that, as you note,
are not included and slow.  Small C programs fixed those.
There are complications for memory allocation, which I avoid
by writing mine to assume (require) that all is already allocated.

(snip)

> At the company I work for, I'm told each Python project will only
> use a certain specified version of Python will never be changed for
> fear of incompatibilities - they treat each version as a new
> programming language :-|

> To bring this back a bit towards compilers - a language definition
> is an integral part of compiler writing. If

I have heard about that one.

It seems that there are non-backward compatible changes
from Python 2.x to 3.x.  That is, they pretty much are different
languages.

Tradition on updating a language standard is to maintain, as much
as possible, backward compatibility.  It isn't always 100%, but often
close enough.  You can run Fortran 66 program on new Fortran 2018
compilers without all that much trouble.  (Much of the actual problem
comes with extensions used by the old programs.)
[Python's rapid development cycle definitely has its drawbacks. Python 3
is not backward compatible with python 2 (that's why they bumped the major
version number) and they ended support for python 2 way too soon. -John]

[toc] | [prev] | [next] | [standalone]

#3444 — Re: Portable Software (was: fledgling assembler programmer)

Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
>My impression was that the FSF favors C and ./configure for "portable"
>code. That's why I understand that any other way is easier for the
>implementation of really portable software, that deserves no extra
>tweaks for each supported target platform, for every single program.

I have not noticed that the FSF has any preference for C, apart from C
being the lingua franca in the late 1980s and the 1990s, and arguably
for certain requirements it still is.

Now C on Unix has to fight with certain portability issues.  In early
times C programs contained a config.h that the sysadmin installing a
program had to edit by hand before running make.  Then came autoconf,
which generates configure files that run certain checks on the system
and fill in config.h for you; and of course, once the mechanism is
there, stuff in other files is filled in with configure, too.

It's unclear to me what you mean with "any other way is easier".  The
way of manually editing config.h certainly was not easier for the
sysadmins.  Not sure if it was easier for the maintainer of the
programs.

>Can somebody shed some light on the current practice of writing portable
>C/C++ software, or any other compiled language, that (hopefully) does
>not require additional human work before or after compilation for a
>specific target platform?

There are other tools like Cmake that claim to make autoconf
unnecessary, but when I looked at it, I did not find it useful for my
needs (but I forgot why).

So I'll tell you here some of what autoconf does for Gforth: Gforth is
a Forth system mostly written in Forth, but using a C substrate.  Many
system differences are dealt with in the C substrate, often with the
help of autoconf.  The configure.ac file describes what autoconf
should do for Gforth; it has grown to 1886 lines.

* It determines the CPU architecture and OS where the configure script
  is running at, and uses that to configure some architecture-specific
  stuff for Gforth, in particular how to synchronize the data and
  instruction caches; later gcc acquired __builtin___clear_cache() to
  do that, but at least on some platforms that builtin is broken
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93811>.

* It checks the sizes of the C integer types in order to determine the
  C type for Forth's cell and double-cell types.

* It uses the OS information to configure things like the newline
  sequence, the directory and path separators.

* It deals with differences between OSs, such as large (>4GB) file
  support, an issue relevant in the 1990s.

* It checks for the chcon program, and, if present, uses it to "work
  around SELinux brain damage"; if not present, the brain is probably
  undamaged.

* It tests which of several ways is accepted by the assembler to skip
  code space (needed for implementing Gforth's dynamic
  superinstructions).

* It checks for the presence of various programs and library functions
  needed for building Gforth, e.g. mmap() (yes, there used to be
  systems that do not have mmap()).  In some cases it works around the
  absence, sometimes with degraded functionality; in other cases it
  just reports the absence, so the sysadmin knows what to install.

That's just some of the things I see in configure.ac; there are many
bits and pieces that are too involved and/or too minor to report here.

Our portability stuff does not catch everything.  E.g., MacOS on Apple
Silicon has a broken mmap() (broken as far as Gforth is concerned;
looking at POSIX, it's compliant with that, but that does not justify
this breakage; MacOS on Intel works fine, as does Linux on Apple
Silicon), an issue that's new to us; I have not yet devised a
workaround for that, but when I do, a part of the solution may use
autoconf.

Now when you write Forth code in Gforth, it tends to be quite portable
across platforms (despite Forth being a low-level language where, if
you want to see them, it's easy to see differences between 32-bit and
64-bit systems, and between different byte orders).  One reason for
that is that Gforth papers over system differences (with the help of
autoconf among other things); another reason is that Gforth does not
expose many of the things where the systems are different, at least
not at the Forth level.  You can use the C interface and then access
all the things that C gives access to, many of which are
system-specific, and for which tools like autoconf exist.

The story is probably similar for other languages.

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

[toc] | [prev] | [next] | [standalone]

#3411

In article <23-03-003@comp.compilers>,
Thomas Koenig  <tkoenig@netcologne.de> wrote:
>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.

Getting more and more off topic, but I can't let this go.

Glibc is a S W A M P.  A newbie who wanders in will drown and never
come out.  Even if you are a very experienced C programmer, you don't
want to go there.

Learning assembler in order to understand how machines work is valuable.
Long ago I learned PDP-11 assembler, which is still one of the cleanest
architectures ever designed. I was taking a data structures course at
the same time, and recursion didn't click with me until I saw how it
was done in assembler.

My two cents,

Arnold
--
Aharon (Arnold) Robbins 		arnold AT skeeve DOT com
[I must admit that when I write C code I still imagine there's a
PDP-11 underneath. -John]

[toc] | [prev] | [next] | [standalone]

#3406

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/

[toc] | [prev] | [next] | [standalone]

#3407

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

[toc] | [prev] | [next] | [standalone]

#3408

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]

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.compilers

csiph-web