Machine-Level Assembly Language

I've heard of a level of assembly language called Machine-Level
Assembly Language. What is Machine-Level Assembly Language?

Brian

Brian wrote:
> I've heard of a level of assembly language called Machine-Level
> Assembly Language. What is Machine-Level Assembly Language?

The obvious alternative would be microcode-level assembly, but without a
context, I can only guess.

--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)

On Wed, 26 Mar 2008 23:40:57 -0400, John W. Kennedy wrote:
> Brian wrote:
>> I've heard of a level of assembly language called Machine-Level
>> Assembly Language. What is Machine-Level Assembly Language?
>
> The obvious alternative would be microcode-level assembly, but without a
> context, I can only guess.

To the OP:
I don't believe there is a class of assembly language called
"Machine-Level Assembly Language". There is machine level coding --
where you would actually toggle the code into the machines via front
panel switches (e.g., the Sys/360 and PDP-8), and/or coding the
instruction stream directly in hex (Sys/360) or octal (PDP-8) and
somehow transcribe that to a media (Hollerith cards: Sys/360 or
paper tape: PDP-8) and use a `loader` to suck in the code and lay it down
in memory.

When you get to "Assembly Language", you require some sort of compiler
to decode/encode the almost-english-like instruction mnemonics into the
actual binary encoding usable by the target machine.

Then there's the topic of Relocatability.........

Jonesy -- Sys/360, et.al., assembler coding from 1966 to 1999.
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts: <http://jonz.net/ng.htm>

On Fri, 28 Mar 2008 06:43:02 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Brian wrote:
>
>> I've heard of a level of assembly language called Machine-Level
>> Assembly Language. What is Machine-Level Assembly Language?
>
>Well, since the current S/3x0 assembler is called High Level
>Assembler, it could be that machine level assembler is the
>non-high level version.
>
>Even so, there are many different ways to use the assembler.
>One can code instructions with absolute constants or symbolic
>addresses. Code such as:
>
> B 12(15)
> DC X'6',CL7'MYNAME'
> STM 14,12,12(13)
>
>used to be somewhat common, where others would use a macro or
>a USING statement for R15 and use a symbolic name for the branch
>destination.
>
>The more symbolic assembler features are used the less
>machine-language like the resulting code.

Then there are assemblers for the microcode portions of various
computers and other devices.
>
>-- glen

You must have been a philosophy major. From a purists standpoint,
toggling in the boot code would be the way to go. But every startup code
I ever did was with a cross-assembler/compiler. You tend to get the job
done quicker that way.

In article <slrnfuo8qv.i85.bit-bucket@shell.config.com>,
Allodoxaphobia <bit-bucket@config.com> wrote:

> On Wed, 26 Mar 2008 23:40:57 -0400, John W. Kennedy wrote:
> > Brian wrote:
> >> I've heard of a level of assembly language called Machine-Level
> >> Assembly Language. What is Machine-Level Assembly Language?
> >
> > The obvious alternative would be microcode-level assembly, but without a
> > context, I can only guess.
>
> To the OP:
> I don't believe there is a class of assembly language called
> "Machine-Level Assembly Language". There is machine level coding --
> where you would actually toggle the code into the machines via front
> panel switches (e.g., the Sys/360 and PDP-8), and/or coding the
> instruction stream directly in hex (Sys/360) or octal (PDP-8) and
> somehow transcribe that to a media (Hollerith cards: Sys/360 or
> paper tape: PDP-8) and use a `loader` to suck in the code and lay it down
> in memory.
>
> When you get to "Assembly Language", you require some sort of compiler
> to decode/encode the almost-english-like instruction mnemonics into the
> actual binary encoding usable by the target machine.
>
> Then there's the topic of Relocatability.........
>
> Jonesy -- Sys/360, et.al., assembler coding from 1966 to 1999.

Allodoxaphobia <bit-bucket@config.com> writes:
> When you get to "Assembly Language", you require some sort of compiler
> to decode/encode the almost-english-like instruction mnemonics into the
> actual binary encoding usable by the target machine.
>
> Then there's the topic of Relocatability.........

don't get me started ... it was one of the severe problems ... the
os/360 relocatable address adcons ... lots of past posts on the severe
problems it gave me
http://www.garlic.com/~lynn/subtopic.html#adcons

the science center in the mid-60s
http://www.garlic.com/~lynn/subtopic.html#545tech

along with starting out with doing the cp40 virtual machine
implementation (also doing hardware modifications to 360/40 for virtual
memory support), also did cms (started out as cambridge monitor system,
was later renamed to converstation monitor system).

cms made extensively use of os/360 language applications (assemblers,
compilers, etc) with emulation of the required os/360 facilities. this
included program link/loader having to support the intermediate
os/360 TXT conventions ... old post with "RLD" format:
http://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games

starting on cp67 (the science center had morphed cp40 to cp67 when
360/67 with standard virtual memory hardware became available), i had
implementated page-mapped filesystem support for cms with a lot of
features for mapping executable files (from the filesystem) into virtual
memory. some old email referencing migrating work from cp67 to vm370
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

while the page-mapped filesystem stuff never shipped in product ... it
was extensively used in internal distributions ... recent reference
http://www.garlic.com/~lynn/2008g.html#48 How did third-party software companies deal with unbundling being sprung on them?

a small subset of the csc/vm support for mapping of objects to virtual
memory was shipped in vm370 release three as DCSS. This somewhat
happened because the demise of future system
http://www.garlic.com/~lynn/subtopic.html#futuresys

and the resulting mad rush to get stuff back into the 370 product
pipeline ... created opportunity for picking up and shipping a lot of
stuff that I had been doing (all thru the future system period) ...
see the above referenced post regarding unbundling.

part of the issue was the original/basic support permitted a page-mapped
filesystem object to be mapped to an arbitrary virtual memory address as
well the same virtual memory object to be mapped to multiple different
virtual address spaces (as shared object) ... and a shared object wasn't
required to appear at the same virtual address in different virtual
address spaces.

the os/360 TXT deck convention for RLD processing ... was that when the
executable object is fetched and mapped to address space ... all the RLD
address constants have to be swizzled to correspond to the loaded
address. These has very adverse effects in a virtual memory environment.
First ... all the virtual pages containing relocatable address
constants, were being prefetched and modified before program execution
could begin (forcing changed status on the page). Second ... once the
relocatable address constants were swizzled to correspond with executing
virtual address ... it was pinned to that address and wouldn't work at
different addresses (eliminating the feasability of having the same
virtual executable object appearing simultaneously at arbitrary
different virtual addresses in different virtual address spaces).

At least this was one area where tss/360 did get it right (and some
number of other operating systems specifically designed for virtual
memory environment) ... which had executable object convention that
allowed for it to be page-mapped with-out requiring all the relocatable
address constants in arbitrary virtual pages to be modified ... as well
as allowing for shared executable image to appear at arbitrary virtual
addresses in different virtual address spaces.

For all the executable images that I would allow to appear at arbitrary
virtual addresses ... w/o pre-swizzling all the relocatable address
constants ... i had to go thru the source and eliminate all such
relocatable address constants. This was complicated by CMS having a
kernel API SVC202 interface that had a convention with a relocatable
address constant (frequently "*+4") following the SVC instruction.
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic

Clark F Morris <cfmpublic@ns.sympatico.ca> writes:
> Then there are assemblers for the microcode portions of various
> computers and other devices.

re:
http://www.garlic.com/~lynn/2008g.html#63 Machine-level Assembler Language

a little x-over from thread in comp.arch about tools for programming
horizontal microcode and vliw ...
http://www.garlic.com/~lynn/2008g.html#56 performance of hardware dynamic scheudling
http://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW

There have been some posts here that this applies to programs
entered manually through console controls.

In almost 40 years I've resorted to this method once. Just once.

Around 1970 my shop exchanged IBM "LCS" with stuff from another
vendor on a 360/75. Before the MFT system we ran crashed, there
was a hint from the messages that there was something wrong with
memory storage keys. Like two of the bits were exchanged. The
key was supposed to be 3 (B'0011') and what appeared to be coming
out was 5 (B'0101'). I keyed in a tiny program to set the first
2K of the LCS to key 3, and the next 2K to 12 (X'C', B'1100').
The program then read out the key into registers. Sure enough, 3
came out as 5, and C came out as A. We called the vendors CEs
back in. They were not real happy about this, particularly since
the box had passed the IBM diagnostics with flying colors, but
they changed the storage key read out, and that fixed the
problem. I'll never know whether the real problem was the key
was stored wrong and read out OK, or if the problem was just the
read out. Plus, the diagnostics should have picked up this
problem, and they didn't.

Now that's coding on the bare metal! It is not something I ever
want to do again!

Other posts here speak of the issue of relocating address
constants. I started out on an IBM 7040. Those of us that still
remember this machine (or the 704, 709, or 709x) will recall that
every instruction, just about, had an imbedded address
constant, or 2 address constants. I can recall seeing the 7040
program loader looping, after the program had been loaded and
before it started while it relocated all these address constants
when it did a big program. My view at the time was the /360 was
a huge improvement. I always worked in OS/360, where program
fetch always relocated address constants. I've been told the
DOS/360 program fetch did not relocate address constants; it
worked like the 7040 binary program loader, and I always thought
that was a serious design defect. Well, at least it was possible
to write programs that could self relocate in /360, which really
wasn't possible in the 7040 scheme.
Brian wrote:
> I've heard of a level of assembly language called Machine-Level
> Assembly Language. What is Machine-Level Assembly Language?
>
> Brian

Steve Myers <noone@nowhere.com> wrote:
> There have been some posts here that this applies to programs
> entered manually through console controls.
>
> In almost 40 years I've resorted to this method once. Just once.
>
> Around 1970 my shop exchanged IBM "LCS" with stuff from another
> vendor on a 360/75. Before the MFT system we ran crashed, there
> was a hint from the messages that there was something wrong with
> memory storage keys. Like two of the bits were exchanged. The
> key was supposed to be 3 (B'0011') and what appeared to be coming
> out was 5 (B'0101'). I keyed in a tiny program to set the first
> 2K of the LCS to key 3, and the next 2K to 12 (X'C', B'1100').
> The program then read out the key into registers. Sure enough, 3
> came out as 5, and C came out as A. We called the vendors CEs
> back in. They were not real happy about this, particularly since
> the box had passed the IBM diagnostics with flying colors, but
> they changed the storage key read out, and that fixed the
> problem. I'll never know whether the real problem was the key
> was stored wrong and read out OK, or if the problem was just the
> read out. Plus, the diagnostics should have picked up this
> problem, and they didn't.
>
> Now that's coding on the bare metal! It is not something I ever
> want to do again!
>
> Other posts here speak of the issue of relocating address
> constants. I started out on an IBM 7040. Those of us that still
> remember this machine (or the 704, 709, or 709x) will recall that
> every instruction, just about, had an imbedded address
> constant, or 2 address constants. I can recall seeing the 7040
> program loader looping, after the program had been loaded and
> before it started while it relocated all these address constants
> when it did a big program. My view at the time was the /360 was
> a huge improvement. I always worked in OS/360, where program
> fetch always relocated address constants. I've been told the
> DOS/360 program fetch did not relocate address constants; it
> worked like the 7040 binary program loader, and I always thought
> that was a serious design defect. Well, at least it was possible
> to write programs that could self relocate in /360, which really
> wasn't possible in the 7040 scheme.
> Brian wrote:
>> I've heard of a level of assembly language called Machine-Level
>> Assembly Language. What is Machine-Level Assembly Language?
>>
>> Brian

DOS/360 didn't relocate while loading. IIRC you had to link the
program to the partition it was going to run in. I assume if you
chaged your partition layouts that you needed to re-link all of your
programs. Fortunately the bank I worked at switched to OS/360.

It always amazed me that anyone could have designed something as bad
as DOS/360; you had to tell the idiot OS where on the disk your file
was if you opened it for write, even though the information was in the
VTOC.
BTW, speaking of program relocation, did you ever look at the various
init routines generated by the IBM COBOL compilers? One of them
relocated a large table of address constants, used to do PERFORM
branching.

Jerry

Jerry Peters wrote:
> It always amazed me that anyone could have designed something as bad
> as DOS/360; you had to tell the idiot OS where on the disk your file
> was if you opened it for write, even though the information was in the
> VTOC.

Historically, DOS/360 was first announced as "BOS/360 16K Disk", an
advanced form of "BOS/360 8K Disk" (later simplified to "BOS/360"). That
says it all, really. At the 1964-66 epoch, there were still plenty of
IBM customers who regarded operating systems, per se, as annoying wastes
of hardware, and the minimum of 32K required for OS/360 as positively
unconscionable.
--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like
That. ...you may come to think a blow bad, because it hurts, and not
because it humiliates. You may come to think murder wrong, because it
is violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"