Machine-Level Assembly Language
Brian
Assembly Language. What is Machine-Level Assembly Language?
Brian
John W. Kennedy
> 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)
Allodoxaphobia
> 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>
glen herrmannsfeldt
> 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.
-- glen
Clark F Morris
Then there are assemblers for the microcode portions of various
computers and other devices.
>
>-- glen
Old Roadie
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.i...@shell.config.com>,
Anne & Lynn Wheeler
Allodoxaphobia <bit-b...@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
Anne & Lynn Wheeler
> 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
Steve Myers
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.
Jerry Peters
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
John W Kennedy
> 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"
glen herrmannsfeldt
> 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.
I probably believe that DOS/360 was fine as a stepping stone
while small machines were affordable and large ones weren't.
I do believe DOS/360 and its descendants have survived
too long, though.
-- glen
Jerry Peters
and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
OS/360 on them at one point, until going to a pair of 370/155's with
1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
Much, much too long. It should have been killed of by say 1980 or so.
Jerry
Steve Myers
fixed long ago (for all I know they have been fixed). I was
always an OS/360 type.
John W Kennedy
> I gotta agree the c***** features of DOS/360 should have been fixed long
> ago (for all I know they have been fixed). I was always an OS/360 type.
Many have, to the extent that it can be done without breaking
compatibility, and, of course, most new features that are added are as
similar to their MVS versions as possible. But, alas, the more systems
grow, the more labor has to be invested to convert, so it always seems
easier not to bite the bullet just yet.
We were lucky. We could see that we were growing quickly, and started
working on OS/360 conversion when we were still using a 360/30. It
helped that we had no pre-360 legacy to cause problems.
--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson
glen herrmannsfeldt
(snip)
> Really small by today's standards. The bank I worked at had a 360/40
> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
> OS/360 on them at one point, until going to a pair of 370/155's with
> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
I thought 64K was a small 360/40.
> Much, much too long. It should have been killed of by say 1980 or so.
I remember some discussion on the overlay feature of
the link editor, and someone disagreed with a statement
I made about it. Sometime later I figured it must have
been the DOS/360 link editor that worked differently.
The OS/360 linker can read its own output (load module).
Can the DOS/360 linker do that?
-- glen
paul hinman
4MB. The systems programmers wanted to upgrade the default region size
from 108K to 384K. Operations practically revolted at the thought until
we were able to demonstrate that that there was plenty of memory to do
it and compiles and assemblies ran so much faster because they didn't
need to use spill files.
Then we proposed a conversion to SVS with HASP, the net effect was to
buy another 10 hours in a day, The previous systems programming manager
did not believe in virtual memory or HASP, the upgrade from MVT without
HASP resulted in an in incredible change in performance.
Jerry Peters
information and probably no symbol info either.
There was some utility that you used to "catalog" object decks to
produce a library of some sort. Don't remember what it was called.
I've worked very, very briefly in DOS/360 environments, many years
ago. Mostly I've worked in MVS environments.
Jerry
> -- glen
>
John W Kennedy
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Jerry Peters wrote:
>> (snip)
>>
>>> Really small by today's standards. The bank I worked at had a 360/40
>>> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
>>> OS/360 on them at one point, until going to a pair of 370/155's with
>>> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
>> I thought 64K was a small 360/40.
>>
>>> Much, much too long. It should have been killed of by say 1980 or so.
>> I remember some discussion on the overlay feature of
>> the link editor, and someone disagreed with a statement
>> I made about it. Sometime later I figured it must have
>> been the DOS/360 link editor that worked differently.
>>
>> The OS/360 linker can read its own output (load module).
>> Can the DOS/360 linker do that?
>>
> IIRC, no.
That is correct. That's why it was called the "core-image library" --
because contents were, bit for bit, what would be loaded into core.
> It could only read object code, since it had no relocation
> information and probably no symbol info either.
The DOS/360 linkage editor could read:
80-byte object decks, and
items from the "relocatable library".
The relocatable library mainly contained pre-assembled I/O modules and
compiler run-time libraries, plus customer-written code.
> There was some utility that you used to "catalog" object decks to
> produce a library of some sort.
MAINT -- which could:
add or replace in the relocatable and source libraries,
delete or rename in the core-image, relocatable, and source libraries,
and, later, update by line in the source library.
There were also CORGZ, which could compress and copy the libraries (DOS
libraries could be compressed from the start; OS did not get the ability
to compress a PDS until years later), and RSERV, SSERV, and, later,
CSERV to print and/or punch.
--
John W. Kennedy
"The first effect of not believing in God is to believe in anything...."
-- Emile Cammaerts, "The Laughing Prophet"
Andy Wood
paul hinman <paul....@shaw.ca> wrote:
>I can remember when a decision was made to upgrade a 370/168 from 2MB to
>4MB. The systems programmers wanted to upgrade the default region size
>from 108K to 384K. Operations practically revolted at the thought until
>we were able to demonstrate that that there was plenty of memory to do
>it and compiles and assemblies ran so much faster because they didn't
>need to use spill files.
>
. . .
I was involved in upgrading the storage on a 155 (last IBM mainframe
to use magnetic core storage?). I think an extra 512K was involved,
but it took much careful consideration over several months.
I couldn't help thinking of that many years later when I needed to
upgrade a PC and I went to a store in the small town I was staying in,
paid cash for 1M of RAM and then walked out with it in a paper bag. I
could do something similar today, but now it might be 1G of RAM I
would walk out with.
Andy Wood
woo...@trap.ozemail.com.au
John W Kennedy
> I was involved in upgrading the storage on a 155 (last IBM mainframe
> to use magnetic core storage?).
The 155 and 165 were contemporaries. The 360/22 came out after them, but
I'd say it doesn't count, since the 22s were just recycled 30s, marketed
as fill-ins until the 370/115 and 370/125 were ready.