The evolution of the mnemonic ORG. Please comment.
Aharon Lavie
to modify the location counter. Since this mnemonic is so
undescriptive of its function, I am curious about the history of its
evolution.
My first encounter with a similar mnemonic was back in the 1960s on a
second generation machine, namely, the IBM-1620, where the assembly
language (its name was not assembler, but some 3-letter acronym which
I do not remember) source code had to start with the directive DORG
(define origin) to set the program starting or loading address. After
that I encountered ORG in its present function on the IBM-360 and on
other computing environments including, of course, the X86.
If anyone here has any additional information about the evolution of
this mnemonic, please comment.
Ed Beroset
For what it's worth, my 1967 edition of the DEC's _Small Computer
Handbook_ (describing the PDP-8 and friends) didn't use such a mnemonic.
The assembler, PAL III, used the asterisk character for that purpose:
*110
CLA / CLEAR ACCUMULATOR
TAD INI / GET ADDRESS OF FIRST COUNTER
DCA YLOC / STORE FOR USE AS POINTER
etc.
However, they explicitly described that as the "origin" so clearly the
term was fairly commonly used in that sense by '67.
Ed
RobeFortu1
I think on the PC platform, ORG started with Gary Kidall's personal computer
operating system, CP/M. Control Program for Microcomputers. ORG is closely
related to .COM files which when written in assembler all have an ORG 0100h in
them. It slips my mind at the moment why this is so but vaguely I recall it has
to do with something using the first 256 bytes of main memory for something.
hth
ben schwartz
and Plette ORG is the mnemonic for ORIGIN. Specifically,
"This mnemonic tells the assembly program to begin assigning memory
addresses at the address given in the (A) Operand. This line of coding
should precede the rest of the program. If the (ORG) mnemonic is not used,
the assembly will begin assigning addresses at memory position 333."
p 97.
If you want to go back further try to find a reference for United Airlines
Symbolic Assembly Program (SAP) for IBM 704 mentioned by Sammet in
"Programming Languages: History and Fundamentals" p. 3
While SOAP for IBM 650 may have been an earlier symbolic assembler earlier
it would not have needed an ORG since the 650 was a drum--not core--machine
and addresses were 3-address (with the first address being the address of
the instruction and instructions were not written in sequence but were
spaced around the drum to minimize execution time loss to latency on
intruction fetch) . The trick for symbolic assemblers for drum machines
(see also UNIVAC SS bi-quinary systems) was to obviate coder calculation of
the next instuction address. But an ORG instruction doesn't make sense when
instructions are scattered rather than sequential.
"Aharon Lavie" <lav...@altavista.com> wrote in message
news:36709618.03081...@posting.google.com...
Alex McDonald
> to modify the location counter. Since this mnemonic is so
> undescriptive of its function, I am curious about the history of its
> evolution.
>
> My first encounter with a similar mnemonic was back in the 1960s on a
> second generation machine, namely, the IBM-1620, where the assembly
> language (its name was not assembler, but some 3-letter acronym which
> I do not remember)
Was it BAL - basic assembly language?
> source code had to start with the directive DORG
> (define origin) to set the program starting or loading address. After
> that I encountered ORG in its present function on the IBM-360 and on
> other computing environments including, of course, the X86.
>
> If anyone here has any additional information about the evolution of
> this mnemonic, please comment.
>
3 letter acronym of ORiGin -- as simple as that. Possibly because O OR OI &
OC (all OR instructions) the truncation ORI would possibly have been
confusing. ORG and EQU directives were (and still are) often confused by
learner programmers.
IBM 360 assembler was cryptic in the extreme; the longest acronyms iirc were
CSECT DSECT USING LTORG, all directives; that is, 5 letters. LTORG was short
for LiTeralORiGin, the address at which literals would be built.
[ 370 (31bit addressing as opposed to the 360's 24bit) and 390 (64bit)
assembler is remarkably similar to 360 BAL; there have been few, mainly
additive, changes since its launch in 1964 (nearly 40 years ago), a
testimony to the original and truly seminal design of the 360. A quote from
the launch; "We are not at all humble in this announcement. This is the most
important product announcement that this corporation has ever made in its
history." It was also at that time that IBM coined the now common phrase
"computer architecture" for the 360. ]
--
Regards
Alex McDonald
Aharon Lavie
> "Aharon Lavie" <lav...@altavista.com> wrote in message
> news:36709618.03081...@posting.google.com...
> >
> > My first encounter with a similar mnemonic was back in the 1960s on a
> > second generation machine, namely, the IBM-1620, where the assembly
> > language (its name was not assembler, but some 3-letter acronym which
> > I do not remember)
>
> Was it BAL - basic assembly language?
No. I remember BAL being used for the IBM-360 mainframe. As far as I
can recall for the IBM-1620, the first of the 3-letter acronym was "S"
(probably standing for "Symbolic") and the second was "P" - my guess
is that the acronym was SPL for Symbolic Programming Language.
>
> > source code had to start with the directive DORG
> > (define origin) to set the program starting or loading address. After
> > that I encountered ORG in its present function on the IBM-360 and on
> > other computing environments including, of course, the X86.
> >
> > If anyone here has any additional information about the evolution of
> > this mnemonic, please comment.
> >
>
> 3 letter acronym of ORiGin -- as simple as that. Possibly because O OR OI &
> OC (all OR instructions) the truncation ORI would possibly have been
> confusing. ORG and EQU directives were (and still are) often confused by
> learner programmers.
I started this thread because ORG, coming out of ORiGin, is not "as
simple as that." Its function, in both the IBM mainframe BAL and in
the X86 MASM, is to modify the location counter at any point in the
program, not necessarily at the program origin. This is probably the
source of confusion for learner programmers, not realising that ORG
has something to do with the origin only at the beginning of the
program, but not at its midst.
As for EQU, the confusion may be caused by the inconsistency in MASM,
using the mnemonic to equate a symbol to a value under some vague
circumstances and to a character string under other vague
cirumstances. IBM-360 BAL is consistent in using EQU to always equate
a symbol to a value, while TASM is consistent in using the mnemonic to
always equate a symbol to a character string.
>
> IBM 360 assembler was cryptic in the extreme; the longest acronyms iirc were
> CSECT DSECT USING LTORG, all directives; that is, 5 letters. LTORG was short
> for LiTeralORiGin, the address at which literals would be built.
>
The coding convention for the IBM-360 used the 80-position IBM cards
and provided some flexibility by allowing somewhat free format coding.
However, it set a coding standard which specified 5 positions for the
operation mnemonic, hence the restriction of directive mnemonics to 5
letters.
Alex McDonald
news:36709618.03081...@posting.google.com...
> "Alex McDonald" <alex...@btopenworld.com> wrote in message
news:<bhon07$pf7$1...@titan.btinternet.com>...
> > "Aharon Lavie" <lav...@altavista.com> wrote in message
> > news:36709618.03081...@posting.google.com...
> [...]
> > >
> > > My first encounter with a similar mnemonic was back in the 1960s on a
> > > second generation machine, namely, the IBM-1620, where the assembly
> > > language (its name was not assembler, but some 3-letter acronym which
> > > I do not remember)
> >
> > Was it BAL - basic assembly language?
>
> No. I remember BAL being used for the IBM-360 mainframe. As far as I
> can recall for the IBM-1620, the first of the 3-letter acronym was "S"
> (probably standing for "Symbolic") and the second was "P" - my guess
> is that the acronym was SPL for Symbolic Programming Language.
Found it -- SPS, Symbolic Programming System. See
http://www.columbia.edu/acis/history/1620.html.
>
> >
> > > source code had to start with the directive DORG
> > > (define origin) to set the program starting or loading address. After
> > > that I encountered ORG in its present function on the IBM-360 and on
> > > other computing environments including, of course, the X86.
> > >
> > > If anyone here has any additional information about the evolution of
> > > this mnemonic, please comment.
> > >
> >
> > 3 letter acronym of ORiGin -- as simple as that. Possibly because O OR
OI &
> > OC (all OR instructions) the truncation ORI would possibly have been
> > confusing. ORG and EQU directives were (and still are) often confused by
> > learner programmers.
>
> I started this thread because ORG, coming out of ORiGin, is not "as
> simple as that." Its function, in both the IBM mainframe BAL and in
> the X86 MASM, is to modify the location counter at any point in the
> program, not necessarily at the program origin. This is probably the
> source of confusion for learner programmers, not realising that ORG
> has something to do with the origin only at the beginning of the
> program, but not at its midst.
Ah, the evolution of the meaning & function of ORG, not why it's ORG. That I
missed.
There is a good example of confusion in a current thread in clax (Newbie
Question on Addressing, posted 14Aug) where the poster asks "What exactly
does the org statement do? I was under the impression that it sets the
initial address in memory where your code resides. What is this address
relative to? The start of memory? The start of the memory allocated to your
program? Or is it dependent on where the program is run from?"
Perhaps other posters can comment on what their favourite assembler means by
ORG, and whether it's usable for other than setting the "program origin"
(that is, it sets the assembler's location counter).
===snipped
>
> The coding convention for the IBM-360 used the 80-position IBM cards
> and provided some flexibility by allowing somewhat free format coding.
> However, it set a coding standard which specified 5 positions for the
> operation mnemonic, hence the restriction of directive mnemonics to 5
> letters.
Which came first, the chicken (5 letter acronyms) or the egg (5 columns)?
--
Regards
Alex McDonald
ben schwartz
Returning to SPS-1 for the IBM 1401 (1959)--a system for which there was no
linkage editor--using ORG to map memory must have been common among systems
programmers using the system. Here's a quote from "IBM 1401 Symbolic
Programming Systems: SPS-1 and SPS-2 Specifications and Operating
Procedures, Form C24-1480-0, p19
"ORG--Origin
... An ORG statement may be included at any d4esired point in the source
program.
This will cause the [instruction] counter to be reset and cause all
future entries to be
assigned addresses beginning at the particular location designated by
the programmer...."
Since SPS-1 also provided for symbolic addresses and * (in the sense of
"here") and + or - adjustment of addresses,
this primitive ORG seems to have had all of the flexibility of later ORGs.
On the other hand, there is no EQUate statement.
As for instruction format: the 1401 goes back to the days of the
professional "key punch operator".
For the most part, programmers probably did not punch their own programs.
The point is that key punch operators prepared programs for key punches that
enforced extremely rigid coding formats.
The SPS-1 format was just that rigid. However, when compared to machine
code, the rigid format and small
field size seemed anything but cryptic. Specifically,
once you got past the coding sheet and line number (columns 1-5) you had
col 6-7: Count field (instruction length or data size)
col 8-13: Label
col 14-16: Op code (actual or mnemonic)
col 17-27: A operand (
17-22: address; 23:+ or - or blank); 24-26: adjustment, 27: index
location)
col 28-38: B operand (same internal format as A operand)
col 39: opcode modifier
col 40-55: comments
col 76-80: program id
While OS360 BAL/ALC, JCL and Utility coding cards had fewer fields, in the
initial releases the format was just as rigid.
Shill
> assembler all have an ORG 0100h in them. It slips my mind at the
> moment why this is so but vaguely I recall it has to do with
> something using the first 256 bytes of main memory for something.
For the PSP (Program Segment Prefix).
Charles A. Crayne
"Alex McDonald" <alex...@btopenworld.com> wrote:
:Perhaps other posters can comment on what their favourite assembler means
by
:ORG, and whether it's usable for other than setting the "program origin"
:(that is, it sets the assembler's location counter).
ORG in MASM and TASM works like the mainframe assemblers, i.e. it sets the
location counter to the specified expression, which may be before, after,
or the same as the current location counter.
GNU as is broken -- the location counter may not be moved backwards, which
greatly restricts is usefulness.
NASM is even more broken. It only sets the initial value.
I don't know about the others.
-- Chuck
Aharon Lavie
> "Aharon Lavie" <lav...@altavista.com> wrote in message
> news:36709618.03081...@posting.google.com...
> > "Alex McDonald" <alex...@btopenworld.com> wrote in message
> news:<bhon07$pf7$1...@titan.btinternet.com>...
> > > "Aharon Lavie" <lav...@altavista.com> wrote in message
> > > news:36709618.03081...@posting.google.com...
> [...]
> > > >
> > > > My first encounter with a similar mnemonic was back in the 1960s on a
> > > > second generation machine, namely, the IBM-1620, where the assembly
> > > > language (its name was not assembler, but some 3-letter acronym which
> > > > I do not remember)
> > >
> > > Was it BAL - basic assembly language?
> >
> > No. I remember BAL being used for the IBM-360 mainframe. As far as I
> > can recall for the IBM-1620, the first of the 3-letter acronym was "S"
> > (probably standing for "Symbolic") and the second was "P" - my guess
> > is that the acronym was SPL for Symbolic Programming Language.
>
> Found it -- SPS, Symbolic Programming System. See
> http://www.columbia.edu/acis/history/1620.html.
>
Whooo-Wha! This brings up very very old memories!
[...]
> > >
> > > 3 letter acronym of ORiGin -- as simple as that. Possibly because O OR
> OI &
> > > OC (all OR instructions) the truncation ORI would possibly have been
> > > confusing. ORG and EQU directives were (and still are) often confused by
> > > learner programmers.
> >
> > I started this thread because ORG, coming out of ORiGin, is not "as
> > simple as that." Its function, in both the IBM mainframe BAL and in
> > the X86 MASM, is to modify the location counter at any point in the
> > program, not necessarily at the program origin. This is probably the
> > source of confusion for learner programmers, not realising that ORG
> > has something to do with the origin only at the beginning of the
> > program, but not at its midst.
>
> Ah, the evolution of the meaning & function of ORG, not why it's ORG. That I
> missed.
>
> There is a good example of confusion in a current thread in clax (Newbie
> Question on Addressing, posted 14Aug) where the poster asks "What exactly
> does the org statement do? I was under the impression that it sets the
> initial address in memory where your code resides. What is this address
> relative to? The start of memory? The start of the memory allocated to your
> program? Or is it dependent on where the program is run from?"
Interestingly, this confusion is not limited to the original poster of
that thread. A responding poster answered: "It tells compiler how to
translate names and labels into offsets." Mind you, the context of
both question and answer in that thread is programming the boot
sector, where ORG 0 and ORG 7C00H are commonly used at the beginning
of the program to define the program origin. In this context the
slightly inaccurate language can be excused.
>
> Perhaps other posters can comment on what their favourite assembler means by
> ORG, and whether it's usable for other than setting the "program origin"
> (that is, it sets the assembler's location counter).
>
> ===snipped
>
> >
> > The coding convention for the IBM-360 used the 80-position IBM cards
> > and provided some flexibility by allowing somewhat free format coding.
> > However, it set a coding standard which specified 5 positions for the
> > operation mnemonic, hence the restriction of directive mnemonics to 5
> > letters.
>
> Which came first, the chicken (5 letter acronyms) or the egg (5 columns)?
This question should be addressed to Poughkeepsie, where, if I am not
mistaken, both chicken and egg were conceived.
It makes sense to me that the specifications came first and the
definitions of mnemonics where adjusted to meet the specifications.
bitRAKE
> ORG, and whether it's usable for other than setting the "program origin"
> (that is, it sets the assembler's location counter).
>
MASM is used by many and its ORG directive is a mess - if you don't
restrain it's use then your going to have unsolvable bugs in your code
(internal error). In MASM ORG can be used not only to set the assumed
E/IP, but also to move about within the assembled code. Here is an
example macro:
pushr8 MACRO val:REQ
REAL8 val
db 068h ; push
REAL8 val
org $-(8+1+8)
nop ; you can replace these with something useful?
nop
nop
db 068h ; push
org $+4+1+4
ENDM
ORG changes the place in memory where assembly takes place. This
seems all fine and dandy, but during use of this macro strange bytes
will begin to appear around where this macro is being used due to some
internal error. I suggest only using ORG at the start of the asm file
(ie don't use the above macro).
I prefer the way FASM uses ORG just to change the internal E/IP used
for code generation of non-relitive code.
bitRAKE
arargh3...@now.at.arargh.com
My only comment would be: that 1401 SPS was quite braindead compared
to AUTOCODER.
I can only think of two reasons that anyone would have used SPS:
a) AUTOCODER hadn't been written yet.
b) You didn't have enough core to run AUTOCODER, which I think
required a 4000 char memory.
<snip>
--
Arargh308 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Frank Kotler
> NASM is even more broken. It only sets the initial value.
Wish you had been in on the fairly recent discussions over how "org"
*should* work in Nasm! For a while there (versions 0.98.08 through
0.98.35), Nasm *did* accept more than one "org" - but you couldn't move
"backwards". I tried to argue that some people *wanted* it to be able to
move "backwards", but I wasn't very persuasive because I really don't
know what use it is! (just heard that that's what some people wanted)
Why would you want to (notionally) emit something and then go back and
overwrite it???
Currently Nasm again accepts only *one* origin. You can change the
location counter by starting a new section with the "start" or "vstart"
property. "start" zero-pads to the new location, "vstart" just changes
the counter and doesn't pad, (some people wanted a second "org" to do
one thing, some the other, so multiple "org"s were rejected as too
confusing) This change was discussed, specified and re-specified, and
batted around for over a year before it went in. I *really* hope we're
not going to have to change it again!
Best,
Frank
Charles A. Crayne
Frank Kotler <fbko...@comcast.net> wrote:
:Nasm *did* accept more than one "org" - but you couldn't move
:"backwards". I tried to argue that some people *wanted* it to be able to
:move "backwards", but I wasn't very persuasive because I really don't
:know what use it is! (just heard that that's what some people wanted)
:Why would you want to (notionally) emit something and then go back and
:overwrite it???
Although there are a few cases where it is desirable to override something
which the assembler has generated, it is much more common to move the
location counter back in order to add alternative labels to the symbol
table.
For example, suppose that one has a sequential file in which each record
has a common header, but different detail fields, some of which have
multiple subrecord types. In theory, one can handle this case with a
different structure for each record type, but in practice, it can become
very complicated. However, with a fully functional ORG, I can do something
like this:
header equ $
type res w ;record type
. . .
detail equ %
;fields for type one records
t1f1 resb 17
t1f2 resd 1
. . .
org detail
;fields for type two records
t2f1 resw 1
t2f2 resb 48
t2subrecord equ $
t2s1f1 resb 32
t2s1f2 resb 14
. . .
org t2subrecord
t2s2f1 resb 128
t2s2f2 resq 1
. . .
org detail
And so forth . . .
-- Chuck
Ed Beroset
> Charles A. Crayne wrote:
>
>> NASM is even more broken. It only sets the initial value.
>
>
> Wish you had been in on the fairly recent discussions over how "org"
> *should* work in Nasm! For a while there (versions 0.98.08 through
> 0.98.35), Nasm *did* accept more than one "org" - but you couldn't move
> "backwards". I tried to argue that some people *wanted* it to be able to
> move "backwards", but I wasn't very persuasive because I really don't
> know what use it is! (just heard that that's what some people wanted)
> Why would you want to (notionally) emit something and then go back and
> overwrite it???
I provided an example at the time, as I recall. The assembly language
version of eforth, which was a simple Forth implementation available on
the web for years, uses such a mechanism to build the Forth dictionary
which traditionally starts from high memory and builds down toward the
user's space. Any such statically created data structure or code will
have the same problem, if the intent is to have the memory space used
starting from high addresses.
> Currently Nasm again accepts only *one* origin. You can change the
> location counter by starting a new section with the "start" or "vstart"
> property. "start" zero-pads to the new location, "vstart" just changes
> the counter and doesn't pad, (some people wanted a second "org" to do
> one thing, some the other, so multiple "org"s were rejected as too
> confusing) This change was discussed, specified and re-specified, and
> batted around for over a year before it went in. I *really* hope we're
> not going to have to change it again!
To my understanding vstart and start are only available if you're
assembling directly to a BIN output. That doesn't really meet the need,
but I guess I've already said all this already. BTW, I just looked in
the docs for the explanation of vstart and it seems to be missing. If
you understand how it actually works (I'm not sure I do) then you might
want to capture that in the nasm docs before you forget. If you want, I
can help with that.
Ed
Frank Kotler
No, you can't do that with "org" in Nasm. You *should* be able to do it
by replacing "org" with "absolute". That worked in 0.97, was broken in
0.98... I think we've got it working again now. I'm a little confused
about how sub-records of different sizes(?) are going to work...
Ed points out that "start" and "vstart" are only available in "-f bin"
output format. This is true of "org", too, so Nasm's "org" would have to
change a lot to work in that way.
Best,
Frank
Frank Kotler
> To my understanding vstart and start are only available if you're
> assembling directly to a BIN output.
True. This applies to "org" also, so it really isn't suitable for what
Chuck wants - assuming he'd want it in other than binary format.
> That doesn't really meet the need,
> but I guess I've already said all this already.
What about "absolute"? (when it's working)? That will only allow "resb",
etc., so it wouldn't be any good for "backing up" over data or code, but
I think it will reserve labels like Chuck's example.
> BTW, I just looked in
> the docs for the explanation of vstart and it seems to be missing. If
> you understand how it actually works (I'm not sure I do) then you might
> want to capture that in the nasm docs before you forget. If you want, I
> can help with that.
All we currently say about "vstart" is:
\b Sections can be given a virtual start address, which will be used
for the calculation of all memory references within that section
with \i\c{vstart=}.
I'm not sure just what we *ought* to say... any ideas? We apparently
need to better document how to get mapfiles out of it, too. It's
evidently not clear that this is a directive to put in the file, not a
command-line option as it would be to a linker. Or maybe it should be a
command-line option... I don't really like introducing a command-line
option that only applies to one output format. I dunno...
Best,
Frank
Beth
> The assembler directive ORG provides the programmer with the
facility
> to modify the location counter. Since this mnemonic is so
> undescriptive of its function, I am curious about the history of its
> evolution.
I actually don't find it at all "undescriptive of its function"
myself...in plain English terms, yes, "origin" means "from whence
things came" and seems a slightly odd word...but it's in its
_mathematical sense_ - in which I believe the word is being used
here - it makes perfect sense, to me, as a mnemonical name for what
the directive is: The "origin" is the point from which you are
measuring things...
As instructions are encoded _relative_ to the current location counter
then ORG makes sense, to me at least, as the original _absolute_
origin from which all these relative "measurements" are being
made...if you've done stuff with polar co-ordinates then this whole
absolute / relative thing should be quite "obvious" as a concept, even
if it just "looks odd" to everyone else :)
Though, granted, this only makes much sense from the _mathematical
sense_ of "origin"...the more general plain English "origin" doesn't
immediately strike you as being all that great a mnemonic, I will
admit...but, I'd say, it does still apply by association (that is,
mathematical "origin" is a restricted specific context form of plain
English "origin"...it hasn't really changed its meaning moving over
once more to assembly but the specific context _does_ mean you have to
look on it in a specific restricted sense...it's starting to pick up a
bit of semantical "Chinese Whispers" - or, if you like, choatic
"butterfly wings" interactions - on its journey :)...
Though, in terms of the "origin of origin" (now there's a pun ;), it's
still interesting to wonder where it came from...because, at the very
least, this opens up the issue that whoever came up with the name
"ORG" (short for "origin") was implicitly assuming every programmer
would be knowledgable about mathematical things...which, of course,
_was_ a generally regarded "fact"...that all programmers were
"inherently" mathematical...so, from a historical standpoint, it's
certainly interesting to note that this once "fact" now has little
basis in being presumed anymore (it never was true, really, but with
modern VB programmers, you certainly shouldn't be presuming you've got
Newton or Pythagoras programming away at the keyboard ;)...
Rightly, though, I'd say...as machines deal in _logic_, not
mathematics...of course, maths is logical and it's usual to think of
data in numerical / binary terms, so it never hurts to know maths at
all...but the sometimes stated "computers are good at maths" isn't
actually strictly true (similar to how "it's all binary" isn't
actually true either because "binary" is actually a means of
representation, NOT the actual nature of the contents of registers and
memory...that's actually voltage levels and so forth...but that's an
inconvenient way to think of things - unless you're an engineer
designing the thing - so everyone abstracts and just considers it
"binary"...further, I'd even stress that bits and bytes are _NOT_ even
"numeric" either...again, it's just customary to think of them in this
way (as any other way would probably confuse rigidly and drive you
bananas quickly: "just multiply engine red by its one fifth blue
shadow and subtract aquamarine, obviously!!" ;) but those bits could
be representing sound or colour or goodness knows what...but,
usefully, you can turn practically everything into a "number" - a
numeric quantity - which is infinitely easier to comprehend and
manipulate :)...older CPUs couldn't manage multiplication or division,
which are two of the basic "standard" arithmetical
operations...floating point isn't entirely accurate all the time
(though using ASM helps with this :) and only in relatively recent
terms is it usual to expect floating point support to be automatically
present on-chip and not in some mathematical support co-processor of
some sort...
[ The dangers of abstraction; In leaving out the "irrelevent details",
you can accidentally come to the wrong conclusions because, in fact,
the "irrelevent details" weren't actually totally "irrelevent" in that
context...as I try to stress, not all abstractions are equal...and
fixed abstractions are the most dangerous of the lot (which, by the
way, is the very thing that gives Orwell's "NewSpeak" its delibrately
limiting nature...make sure the fixed abstractions can't deal with
"rebellious thought" and those who have no choice but to think in
those fixed abstractions can't break out of that limiting box...even
when not delibrately malicious, any fixed abstraction - like "it's all
binary" (_including_ similar inaccuracies like "black people are
inherently criminal" or "women are incapable" or "All Jews are seeking
world domination", _even_ if you can find one or two instances where
this turns out to be true (though, usually, that turns out to be
caused _exclusively_ by self-fulfilling prophecy...it is _made_ to be
the case by the very prejudice itself: the black man is _made_ a
criminal as the poverty - though no excuse - makes that sort of life
attractive compared to the pile of crap offered instead...the woman is
_made_ incapable because prejudice denied her gender education
opportunities...or, indeed, a _particular_ _individual_ Jew might
decide to want to dominate the world but probably due to constant
mistreatment and buying into the usual bullcrap that power and money
would make all the prejudice disappear...which, in this case, clearly
can't be true becasuse, ironically, a large part in the usual
prejudice against Jews is actually _because_ they were the religion
that was allowed to charge interest (Christians actually aren't
supposed to do this but it became so inconvenient, they eventually
decided to just "ignore" that directive in the Bible)...hence, they
tended to be rich amongst those who were not and simple _envy_ entered
into the prejudical equation...hence, the stereotypical "Shylock"
character of the Jew counting his gold and demanding his "pound of
flesh", as, supposedly, "all Jews" were "evil" because of their
"inherent greed"...so, now that Christians ignore the bit about not
charging interest, which Christian-based nations end up the greediest
of the greedy...literally fulfilling the "pound of flesh" which,
interestingly, actual Jews _never did_ when it was their turn to be
the ones accused of "greed"? Indeed...remember, it's a universal law:
in the end, everything turns out to be deeply ironic...anyway, you
simply can't prove an "always" by example...it's logically
_impossible_)- has the potential to lead to false
conclusions...learning another language helps massively in this...it's
really not just a case of "being polite" when you go on holidays (US:
vacation) to be able to speak with people in their own tongue...seeing
the world through different eyes will massively open your own eyes to
things you previously couldn't even see, even if you never once
exercise, say, your Spanish in Spain or Mexico...also, consistently,
multi-lingual education _practically_ proves this, as those schools
which use multiple languages simultaneously very often consistently
get better results in comparison to their monolingual
counterparts...only a modest amount better, perhaps, but it's a
_consistent_ result...so it benefits _all_ who go through it and, no,
they don't "learn less" (as some suggest might be the case) because
they learn both _simultaneously_...notions expressed in one tongue are
automatically comprehended in the other tongue because, inside your
head, it's a _concept_, not a set of words...don't confuse notation
for what is being notated, remember ;)... ]
Computers aren't good at maths, really...nor is everything
"binary"...heck, it's not even implicitly numeric, after all...so,
though it can't ever hurt to be mathematical, _logic_ (boolean variety
:) would be the true prerequisite here, not mathematics...thus, from a
historical point of view, it's interesting to note that there is this
implicit assumption that all programmers will be at least mathematical
enough to know the jargon...all the way up to things like universities
insisting that you've already qualified on some "basic mathematics"
course as a prerequisite...
It can't hurt because the mathematical mindset _is_ related to the
logical mindset (you need to appreciate logic to do maths properly, in
short :)...so, if you know maths then you're going to breeze over all
this "logic" stuff about binary and "OR" gates and so forth...but,
actually, mathematics is actually too "high-level" here...you _can_
get through this stuff quite competently, I'd say, with just basic
arithmetic skills (adding, subtracting, multiplying, dividing
:)...because, after all, the machine itself only just manages
multiplication and division (usually being among the slowest machine
instructions - if present at all - and likely to be either complexly
hard-wired or microcoded...that is, they aren't logically "low level"
machine-like operations...strictly, only addition and subtraction are
this...mutiplication and division are really just "convenient
shorthand" for a heck of a lot of addition and subtraction...that's
why some older CPUs _can_ get away with no built-in support beyond
adding and subtracting because you can mimic one with the other...and,
in a sense, "to the power of" is just the same style of "convenient
shorthand" applied to multiplication too...e.g. 2 + 2 + 2 + 2 = 2 * 2
* 2 = 2^3 ;)...
So, on a historical note, this connection to mathematics and
presumption you already think in a mathematical way is very
interesting and betrays the engineers "bottom up" view when they
discovered these things...on the other hand, a modern VB programmer
can easily get away with practically no skills beyond basic arithmetic
(even those could be avoided theoretically but that's really going to
make programming a complicated affair :)...I may know about
mathematical concepts but, in the end, I tap everything into a
calculator program to save time when programming, anyway...I could do
it by hand but I don't need to...and, thus, someone who doesn't know
how to do it by hand could conceivably proceed without any knowledge
of how it works at all...well, okay, you'd probably need primary level
"adding and subtracting lego blocks" appreciation of mathematics,
merely to comprehend the nature of "counting" and so forth just to
understand what "numbers" actually are...but you really _don't_
specifically need to be all that much higher-level than that to
program, as it's _logic_ not _mathematics_ that really counts
here...if you can comprehend bits, "OR", "AND", etc. then, though
certain optimisations won't be obvious without a mathematical
appreciation of certain mathematical relationships, you don't really
"need" it exactly...it's just makes things quite a bit easier to
comprehend...
In a funny sense, it should be "basic logic" that's a prerequisite for
mathematical courses and not the other way around, as is actually the
case...but such is history...Boolean logic and that sort of thing was
discovered _after_ basic mathematics so, for purely chronological
reasons, it dominates and is the thing that, historically, people
presume is the lowest level...it's not though...logic is lower level
and it's NOT quite the same thing as mathematics...in fact, maths is a
_higher-level_ discipline (to which logic makes a very good
introduction to...except that _everyone_ always learns this stuff
"backwards", so to speak...because humans - thinking in our "fuzzy
logic" way - are starting from the highest level and are "unlearning"
abstractions to reach the elements rather than the other way
around...weird, huh? But quite logical :)...
Beth :)
Alex McDonald
"Frank Kotler" <fbko...@comcast.net> wrote in message
news:3F47188A...@comcast.net...
The high water mark for any assembled code is recorded; ORG (no operands)
sets to this.
--
Regards
Alex McDonald
Alex McDonald
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:0sJ1b.4560$tS2.2...@newsfep2-win.server.ntli.net...
> Aharon Lavie wrote:
> > The assembler directive ORG provides the programmer with the
> facility
> > to modify the location counter. Since this mnemonic is so
> > undescriptive of its function, I am curious about the history of its
> > evolution.
>
> I actually don't find it at all "undescriptive of its function"
> myself...in plain English terms, yes, "origin" means "from whence
> things came" and seems a slightly odd word...but it's in its
> _mathematical sense_ - in which I believe the word is being used
> here - it makes perfect sense, to me, as a mnemonical name for what
> the directive is: The "origin" is the point from which you are
> measuring things...
>
> As instructions are encoded _relative_ to the current location counter
> then ORG makes sense, to me at least, as the original _absolute_
> origin from which all these relative "measurements" are being
> made...
Very confusing! Instructions are "encoded" absolute to the location counter;
in fact, right at it, at a zero offset from it. It depends on the assembler
(some are more broken than others in this respect) but in the main (and as
the OP suggest in his subsequent posts) ORG sets the location counter. It is
an absolute value and isn't a "relative measurement" (unless you're counting
"relative from zero" which I would consider absolute).
> if you've done stuff with polar co-ordinates then this whole
> absolute / relative thing should be quite "obvious" as a concept, even
> if it just "looks odd" to everyone else :)
In two dimensions, perhaps. Assemblers and ORG operate in one, and there's
nothing relative about it that I can see. ORG's operand is an absolute
value.
===snipped
> ...that's
> why some older CPUs _can_ get away with no built-in support beyond
> adding and subtracting because you can mimic one with the other...and,
> in a sense, "to the power of" is just the same style of "convenient
> shorthand" applied to multiplication too...e.g. 2 + 2 + 2 + 2 = 2 * 2
> * 2 = 2^3 ;)...
As an aside, the machine the OP referred to couldn't even add or subtract.
The IBM 1620 was originally codenamed CADET -- Can't Add Doesn't Even Try.
All arithmetic was done through tables loaded into storage.
> So, on a historical note, this connection to mathematics and
> presumption you already think in a mathematical way is very
> interesting and betrays the engineers "bottom up" view when they
> discovered these things...on the other hand, a modern VB programmer
> can easily get away with practically no skills beyond basic arithmetic
> (even those could be avoided theoretically but that's really going to
> make programming a complicated affair :)
Homo sapiens visualbasicus is operating at a higer level of abstraction?
> ...I may know about
> mathematical concepts but, in the end, I tap everything into a
> calculator program to save time when programming, anyway...I could do
> it by hand but I don't need to...and, thus, someone who doesn't know
> how to do it by hand could conceivably proceed without any knowledge
> of how it works at all...well, okay, you'd probably need primary level
> "adding and subtracting lego blocks" appreciation of mathematics,
> merely to comprehend the nature of "counting" and so forth just to
> understand what "numbers" actually are...but you really _don't_
> specifically need to be all that much higher-level than that to
> program, as it's _logic_ not _mathematics_ that really counts
> here...if you can comprehend bits, "OR", "AND", etc. then, though
> certain optimisations won't be obvious without a mathematical
> appreciation of certain mathematical relationships, you don't really
> "need" it exactly...it's just makes things quite a bit easier to
> comprehend...
>
Logic circuits can be designed that count, add, subtract; but that's just
another way to do it. You for instance can add two numbers together without
a single AND, OR or NOT gate in your brain. Boolean logic (a branch of
mathematics) is not the "foundation" of, nor is it at a "lower level" than
mathematics (by which I take it you mean arithmetic). Set theory is
mathematics' foundation.
===snipped
--
Regards
Alex McDonald
Beth
> I started this thread because ORG, coming out of ORiGin, is not "as
> simple as that." Its function, in both the IBM mainframe BAL and in
> the X86 MASM, is to modify the location counter at any point in the
> program, not necessarily at the program origin. This is probably the
> source of confusion for learner programmers, not realising that ORG
> has something to do with the origin only at the beginning of the
> program, but not at its midst.
Depends on your perspective, really; As I mentioned in my other post,
I look on "ORG" in the more mathematical sense of "the point by which
things are measured"...what things? Why, instructions in this
case...the point from which instructions are "measured"? Sure, sounds
like one possible description of the purpose of the location counter
because that's the _absolute_ starting point from which subsequent
instructions are _relatively_ encoded from...
Note, mathematically, you can change your "origin" all the time, no
problems...hence, the mathematical rather than Plain English semantics
make the meaning clearer, I believe...in the Plain English meaning,
it's normally referring to someone's geographical place of birth or
the source of their family tree or even the beginnings of the human
race itself ("origin of species")...
Well, all these things are _historical_ and you can't change the
past...so, if you're not looking at it from a mathematical
perspective, I can perfectly understand this "Huh? How can it be an
'origin' when you can change it all the time?" thinking...historical
origins are, indeed, quite _singular_ in nature and can't be changed
at all...history is, by its nature, immutable...it's an inherent
property of time (as we currently know it): it keeps moving forward
and you can't go back in time to change things...
On the other hand, mathematics is so abstract it's not even really
inside the spacetime continuum at all...for dynamic systems where you
_want_ time to be a factor, you actually have to _artifically_
introduce it with all that subscript notation stuff (which brings us
to the infamous mathematical nonsense of "x = x + 1", as an
example...this does actually make sense in programming because,
inherently, machines are dynamic systems where _time_ really is an
inherent factor you can't escape (though, in mathematics, it's not
there unless you _introduce_ it :)...thus, in mathematical notation,
it's really "Xt = X(t - 1) + 1" (sorry, can't write subscripts
properly in ASCII...the "t" and "(t-1)" are subscripts, the rest
isn't...and "t" represents a variable keeping track of the continuing
movement of time...though, even with this notation, maths still allows
you the impossibility of decrementing "t" and abstractually moving
backwards in time :)...there's no real need to add this to the program
source, though, because it's an inherent property of the machine and
you can't escape it...time and tide wait for no-one...
It's all wrapped up in this very, very subtle difference in "ordinary"
versus "mathematical" semantics...note, though, that the semantics of
"origin" actually _aren't_ changed at all in both senses...the
difference is that Plain English "origin" is normally tied to _time_
and you can't do anything about that...hence, there is only _one_
singular "origin" for the usual Plain English meaning...
On the other hand, if you do a lot of geometry and think in a
mathematical mindset, then multiple "origins" are perfectly
acceptable...it's just a change in the nature of your
perspective...your starting point for measurements...time isn't an
inherent property of mathematics so, in a sense, when you re-arrange
an equation or change your origin, you're just changing your
perspective on things..."time" doesn't really exist here so, in a
manner of speaking, no "time" at all passes while you're doing this
(in a mathematical sense...in a real-world sense, you can't do this
all instantly so time will pass as you calculate your equations and
results :)...time is "frozen" while you calculate and, weirdly, from
the perspective of any "time" in your equations, those equations (were
they capable) would be amazed by your remarkable ability to seemingly
be able to comprehend things from infinite perspectives all at the
same time...if philosophy is your thing, then if there is a God (or
god or gods or spirit or whatever of the million names humans use)
that exists outside the constraints of space and time, then it's an
interesting philosophical thought to consider that they would see
things in this mathematical sense...it's one of the slip-ups aethists
would make challenging that any god couldn't possibly be
omniscient...no, not by the rules _we_ live by, that's entirely
true...but you're failing to see how much of a massive difference a
simple change in perspective can be...this would be as much "magic" to
time-constrained on-lookers, as the infamous "take technology back
into the past to show people and they'd probably burn you as a 'witch'
for all your 'evil black magic', refusing to listen to your simple
explanations of how it actually works and isn't 'magic' in any way,
shape or form, in fact" ;)...
Thus, as I say, I personally find "ORG" (as in ORiGin :) to be
perfectly mnemonical and appropriate...but then that's just because,
coincidentally, I did look at it in the mathematical sense immediately
so the pieces of the puzzle fell into place...had I seen it from the
Plain English semantics as you do and the inherent "there can be only
one" restriction that applies to "origin" when used on humans and so
forth...well, yeah, I'd be just as confused as you and posting the
same questions...
The word, I'd say, isn't in any way "wrong" or "inappropriate"...you
were just looking at it through the "wrong" or "inappropriate"
lens...put on these mathematical glasses - which have no constraints
on multiple origins because they are only your "point by which to
measure things from", which is the basis of your perspective, which
you're free to change at will - and it shouldn't look fuzzy
anymore...coming into clear as crystal focus :)...
The choice of word, though, _is_ potentially misleading...the fact
that you (and probably many others :) have been misled proves
that...so, perhaps it really should have undergone a bit more thought
and something "perspective-friendly" chosen (the mathematical sense is
actually "perspective-neutral", so to speak...but, in this case, being
"neutral" and "objective" about things is actually the cause of the
confusion because, usually, no-one is "neutral" or "objective" when
they use this word in Plain English semantics)...
Anyway, regardless, the history of the evolution of the mnemonic is
still perfectly interesting, as it will explain _why_ the person who
invented this was thinking that the mathematical perspective was a
valid presumption...it's not actually "obvious" because computers are
_dynamic systems_ constrained by time so, really, the mathematical
perspective is NOT the natural bedfellow (really, you're thinking in
the right context, so to speak, and it's interesting to find out why
the person who thought up "ORG" wasn't...too many geometry lessons at
school warping their minds? Or some academic insistance that software
should be looked at from a mathematical perspective - "prerequisite:
mathematical instruction" not being at all uncommon on a university
prospectus for a computer course, even though it's really _a logical
mindset_ that's the true prerequisite - because of typical academic
prejudices that anything that isn't mathematical is an "art" and
something to pour scorn over as "fanciful" and "imprecise"...truth is,
what scientists claim, we can't totally be "objective" and detach
_personal_ _human_ prejudices from our actions...you try, to be a good
scientist, but you will always fail in some regard...the trick is to
fail on some irrelevent point - your _personal_ interest in astronomy
is your "prejudice" (you _chose_ to be an astronomer, after all, for
purely subjective personal reasons) - but this doesn't (or shouldn't)
effect the validity of your observations so that's an "okay prejudice"
by scientific standards...it effects _what you decide_ to observe but
_shouldn't_ effect the results of that observation, if you're doing
things properly and detaching what you want to find from what you
actually do find...unfortunately, some don't seem entirely capable of
this at all times ;)...
It's good that you phrased it in this way above, as it's allowed me to
pinpoint the "perspective problem" here...the point is that a "program
origin" isn't necessarily a singular entity...yes, that seems
initially "odd" and "weird" because _human_ "origins" are always
singular (due to the nature of time...your great grandfather can't
suddenly change origin - becoming Polish rather than Swedish - so
these kinds of origins are _always_ "singular"...it is the realm of
silly sci-fi films to ponder the idea of things like this suddenly
changing half-way through your life because someone went back in time
and messed around with the "origins" of things, changing them all
about...although, truth be told, the past is such a delicate thing and
prone to choas on a massive scale that any manipulation of the past
before our lives would almost certainly result in all of us
immediately ceasing to exist...or, at least, that's the scientist in
me speaking there...I personally like the notion of "fate" and
"kismet" and such, even if I have no evidence or grounds (yet...I live
in Hope :) by which to demonstrate it as "fact" of any kind...are
"soulmates" fact or emotional illusion? I'll give two completely
contradictory answers depending on whether I'm wearing my "science
hat" or not at that particular moment...as I say, you can't really "be
objective" as people suggest scientists can...the best you can expect
is that the scientist take pains to distinguish the two and not
"infect" you with their own personal prejudices...I try to respect
other people (a subjective thing, again, note) and try to do it
"properly" for your benefit...as noted, I _will_ fail but at least I
recognise the problem and am trying to minimise the effects...far too
many scientists really do think they can put themselves in the
position of God...I'm a touch arrogant at times, granted, but NOT in
that direction or context at all...that's not just silly and
inaccurate and illogical, it's quite blasphemous too...not that
aethists would care about "blasphemous" in the slightest, I do
realise, as, to them, there's no-one to be blasphemous too...ooh, all
this changing perspective and "origin" to attempt to be empathetic
might, indeed, be mathematically possible but it sure does cause a
person a big headache thinking in twenty directions all at the same
time ;)...
Anyway, anyway..."Its function, in both the IBM mainframe BAL and in
the X86 MASM, is to modify the location counter at any point in the
program, not necessarily at the program origin"...the presumption that
your Plain English perspective is misleading you with is that it's
"_the_ program origin"...when, in fact, it's not necessarily singular
(you could have entry points all over the place and load in code in
any old order...worse, into virtual memory, which isn't even holding
the logical addresses in that particular order physically...the memory
pages could be all over the RAM with the "origin" as you think of it
being _after_ the end of the code from the perspective of its source
code order...generally, though, programming languages, OS
architectures, exectuable loaders and so forth all respect the "one
origin" perspective as far as is possible...you might have heard the
common "only have one entry and one exit from a procedure" programming
style advice...but that's "convenience" rather than "actuality", so to
speak...procedures and programs can have multiple entry points and
exit points and be highly fragmented with no particular physical order
to them at all...it's generally considered "poor style" because that
would be a highly confusing mess to unravel (as you demonstrate,
humans are so trained in the notion of singular "start here, end
there" because of having to deal with concepts like time inherently in
practically everything we deal with, that it's "poor style" because it
violates this and sets up the perfect confusing situation that no-one
else will be able to unravel very easily :)...
There, in a sense, is no _the_ program origin...after all, the data
and stack are also part of a program too and can commonly be set quite
independently of the code...so, is this three "origin"s? Or one origin
"plus extensions"? Or a case of there not really being an origin at
all but this is a convenient abstraction for programmers to use
(which, generally, the simple "dump the load image in memory" loaders
support and compliment that you usually never have to think from a
different perspective on this at all :)? And that's the "simple"
situation...what about program libraries with no "official starting
point" but entry and exit points all over the place? Worse, they are
split into multiple files and can be loaded into any order and even
further confused as to logical order by virtual memory mechanisms...
Nope, don't confuse the notation for what's being notated...the
location counter has, in fact, no meaning outside of the assembly
process (there is, indeed, the "program counter" which can often
mirror the location counter sometimes in certain ways...but, nope,
it's a _completely different_ thing, really...the program counter
respects branches, the location counter does not :)...
Anyway, I stress, there's no "right" or "wrong" here...your
perspective is just _different_ from that of the person - presumably a
mathematically-trained engineer or something like that - who came up
with the mnemonic...from your view of things, it's a bad choice of
word and you'd have picked something different...doesn't really
matter, they're all arbitrarily chosen, anyway...after all, we're
saying "origin" but, in fact, the directive is "ORG"...that's not even
an English word...it's just the "agreement" (well, not really
agreement...a case of "here it is...like it or lump it"
you've-got-to-agree-whether-you-want-to-or-not "agreement" ;) that
it's a nice shorthand that's easy to remember...
If you've used other non-IBM influenced assemblers then this is all a
moot point usually because they'd be some sort of "* = $5000"
construction instead or something like it (where "*" is the symbol for
the location counter, like "$" is on Wintelly-like machines...and it's
"*" rather than "$" because they've arbitrarily chosen to use a "$"
prefix for hex numbers rather than "h" suffix :)...
That's one rather minor benefit to C-style symbol-based operators
rather than mnemonic "words", they are usually (stress on usually, as
I'm about to present an example where it's _still_ open to debate :)
outside natural language perspective so there's never any disputes
over whether something was named properly...
Although, that said, is COBOL "better" because it uses a full stop
(US: period) to end statements (semi-colons are, of course, the next
most logical "nautral language" symbol to use because they are close
in semantics to a full stop...a sort of "full stop that isn't"...and
the preference for that, initially, I'd presume is totally a lexical
thing...full-stops are also overloaded as decimal points (and, also,
commonly referencing structure members...commas would also be under
consideration but, well, are already used for any "lists" - again,
borrowed from natural language - so we wouldn't want to flood a
program's source with commas everywhere ;) too...it's just a whole lot
easier to parse if you try to avoid multiple uses as much as
possible...though, practically all languages fail to completely avoid
double-meanings on operators that you've got to wonder if, at least in
this one regard, COBOL wasn't totally off its rocker...anyway, too
late...everyone's got used to the other styles and aren't going to
change, however "appropriate" it is from a "natural language"
perspective :)...
> This is probably the
> source of confusion for learner programmers, not realising that ORG
> has something to do with the origin only at the beginning of the
> program, but not at its midst.
Actually, here's the "slip-up", so to speak...the ORG _does_
potentially have something to do with the origin in its midst too
(writing bootsector code, in fact, I commonly would always use at
least _two_ ORG statements - tool permitting - one to locate the start
of the code at 7C00h, as is a bootsector requirement...but, also, a
second one to make sure that the 0AA55h "BIOS signature" - used to
verify its a valid bootsector with BIOSes that can actually be
bothered to check validity (not all do :) - is at its fixed position
at the end of the bootsector...the tool normally just zeroes out or
leaves untouched any intervening bytes...which is okay, as they won't
be used, other than perhaps as a place to stick a very small initial
stack to allow CALLs statements and such :)...
Depending on your perspective; This is either a misnamed directive (as
it's implying only a singular origin when there actually is no logical
constraint on programs to obey this) or it's correctly named (the
mathematical "origin" has no problems at all with multiple, changing
origins :) and just slightly misleading...or, unlike you and me,
someone out there might think it's both correctly named and not
ambiguous or misleading at all (presumably the person who invented it
was of this opinion or they'd probably have thought up a different
mnemonic instead :)...
It's the dual picture of the woman or the doctor who prescribes
glasses without diagnosis that I've mentioned a few times
before...it's not the _object_ that's "wrong" or "inappropriate" in
this case...it's the "lens" by which you're looking at the
object...you've got your reading glasses on when you're not reading or
vice versa...easily done, though, as you'd forget they were even there
on the end of your nose, if they didn't keep slipping all the time
which reminds you to push them back up so they don't fall off ;)...
Beth :)
Beth
> Charles A. Crayne wrote:
> > NASM is even more broken. It only sets the initial value.
>
> Wish you had been in on the fairly recent discussions over how "org"
> *should* work in Nasm!
[ Then you'd glad that I _wasn't_ in those discussions, they would
have gone on for years and years :) ]
> For a while there (versions 0.98.08 through
> 0.98.35), Nasm *did* accept more than one "org" - but you couldn't
move
> "backwards". I tried to argue that some people *wanted* it to be
able to
> move "backwards", but I wasn't very persuasive because I really
don't
> know what use it is! (just heard that that's what some people
wanted)
> Why would you want to (notionally) emit something and then go back
and
> overwrite it???
Read my other posts here on this matter, Frank...if you think of "ORG"
in its mathematical sense (as in the point where the X and Y axis
cross on a graph being the graph's "origin"...normally, "(0, 0)" but
theoretically capable of being _any_ value and even _changed_ all the
time...polar co-ordinates (rather than Decartes' traditional "fly in a
tent measuring system" ;) are sort of continually changing the
"origin" with every vector (well, effectively, though not strictly by
the jargon)...though a perfect equivalent to Cartesian co-ordinates,
it's interesting to note how little use polars actually get in normal
use...the likely reason? Way too complicated and all this "effectively
changing origins every time" nonsense far, far too confusing ;)...
Then, in fact, the "backwards" and "singular" restrictions are just
really, really _weird_ sounding...enforcing "chronology" in a context
where there is no "time"? Why enforce a time variable on something
that doesn't need it at all? Worse, source code is rarely written from
top to bottom in chronological order - even with assembly which tends
to be better than most on this - so this restriction is even more
weird...you're forcing strict "time" onto something that isn't even in
chronological order?
[ Man, and I thought it was dumb that macros and procedures in most
tools won't permit the logical program layout to deviate from the
physical layout in some cases...hard to clearly explain this
one...it's sort of like "inline functions"...that is, I can write a
section of code elsewhere - for logical, "modular" reasons - and then
include it "inline" in some other procedure...no need for an
unnecessary "CALL" as it's not being split off for "procedure" (code
re-use) reasons but for "modular" reasons of wanting to put related
code together in a single file...macros _would_ be the solution _if_
only they could be "prototyped" and defined elsewhere...anyway, this
is all to do with the standard "phased" way programs are put
together...it's not really a "failing", so to speak, it's just
something I'd Love to see in assembly tools...for a very rough
example:
---------------------------
.code
_start: call InitVideo
...
call FreeVideo
call ExitProcess, eax
---------------------------
Well, I only need to execute "InitVideo" and "FreeVideo" once so
making them procedures and adding CALL is strictly unnecessary and
doesn't gain me anything...but, at the same time, most macro system
won't allow me to just put "InitVideo" and "FreeVideo" without the
actual macros being included first...what's missing here that I reckon
I could make use of is a means to "prototype" macros, just like you
can do with procedures so that I could neatly write the "InitVideo"
and "FreeVideo" code in their own ASM file (nice and modular
there...and not "ugly" being forced into header files, which I'd
prefer to reserve for only public declarations of a module :) but
they'd be _macro-like_ in that the code is dumped straight into the
_start procedure here _without_ any "CALLs" which aren't needed...the
machine doesn't need the CALL and I don't need the ugliness of
stuffing entire procedures into header files because it won't expand a
macro that isn't already defined...neither of us - me or the machine -
should be forced by an ill-thought "phased" process to follow a
substandard way (either worse performance or making source code less
readable :) of doing things because RAM sizes were crap in the late
summer of 1953 or whatever...and no-one has been bothered to
reconsider things with the abilities of modern hardware that _can_
load GBs of data into virtual memory (perhaps even _physical RAM_
these days, as 1GB RAM isn't at all unheard of :)...and doesn't need
to do all that "multiple pass" / "phased tool chain" nonsense for
hardware limitation reasons any more...
Of course, to get around this requires a total redesign of tools to
throw out the whole "tool chain" concept as it currently stands or to,
like C++ compilers do with "inline" functionality, "cheat" by stuffing
extra information into object code...
Ironically, I'm agreeing with Rene's "one tool" concept but actually
_because_ I want multiple file modularity and so forth...hilarious
really, as that's the "anti-Christ" he was actually trying to
annihilate...I'm sure I must have once offended the "gods of irony" or
something because all they ever do is plague me with their highly
comical "revenge" at all opportunities...I probably shouldn't have
earlier poked some fun at the Norse god Loki, as this stream of
practical jokes and ironic pestering is his trademark all
over...thankfully, though the "evil" counterpart of Odin, he's not
like satan...he just likes a good joke at people's expense, he doesn't
normally do anything too nasty, though...fingers crossed...hehehe ;) ]
> Currently Nasm again accepts only *one* origin. You can change the
> location counter by starting a new section with the "start" or
"vstart"
> property. "start" zero-pads to the new location, "vstart" just
changes
> the counter and doesn't pad, (some people wanted a second "org" to
do
> one thing, some the other, so multiple "org"s were rejected as too
> confusing) This change was discussed, specified and re-specified,
and
> batted around for over a year before it went in. I *really* hope
we're
> not going to have to change it again!
Hey, if you've got a bit of rebellious streak in you, why not suggest
that, instead, "*" stands for the location counter and that something
like "* = $1000" (found on some non-Intel assemblers as their version
of "ORG"...NASM accepts "$" as a hex prefix, yes? Does it also
recognise "$" as the location counter value? I must check that out :)
be used instead? That you can arbitrarily assign new values _to_ the
location counter as and when you feel like, as much as you can take
its current value just as freely...without the semantics of "ORiGin"
hiding behind the mnemonic, the concept of "time limiting" it starts
to show up - at least to me - as a bit strange (the symbolic syntax
automatically giving a more "mathematical" perspective on what the
directive is _actually doing_ :)...
Multiple ORGs can have their uses; In a bootsector, you can have "ORG
7C00h" before the code and "ORG 7DFEh" before the BIOS
signature...doesn't matter what the size of the code is, you're
automatically skipping over any extraneous bytes...and no need for
that NASM-esque arithmetic "TIMES 512 - $" stuff...much more readable
to immediately see that the code starts at 7C00h and the BIOS
signature is at 7DFEh...no maths involved, the absolute addresses are
there - plain as day - to be read from the directives...the
"arithmetic" way to pad out the extraneous bytes works, of course, but
isn't it a bit unnecessarily "ugly", merely to keep with some very
weird "source code must be laid out chronologically" concept...never
understood that with "prototypes" either (which ASM has always usually
been good in never requiring by just picking things up in multiple
passes :)...code should, in my view, be in _logical_ order and it can
often do my head in that I'm forced by tool design to make things
"chronological" for no particular reason...a concept which totally
falls apart for multi-threaded code...the threads run simultaneously,
what would "chronological" even mean in this context?
Some other examples; If you're allowing conditional assembly then it's
quite useful to allow going backwards in the code too...define a chunk
of memory with "default" values...it hits a conditional block which
then "backtracks" and inserts different "non-default" values based
upon addresses of things later on in the code (the actual condition
only being calculable at that later point in the code so you've no
option but to "backtrack"...you can't "force" it to be
"chronological", whether you like it or not :)...a totally
"non-chronological" operation...why disallow it?
Heck, this is _assembly_...why disallow _anything_? That's just not in
the spirit of assembly at all...total Liberty to do whatever the
machine allows...when will assembler authors stop _limiting_ and start
_expanding_ (there is a reason I back HLA, Randy...you _add_ extra
features to allow people to make up their own minds...not subtract
things into your own personal view of what "real assembly" is and
prohibit anything else...watch that NASM-ites! "No red tape" is
_exactly right_...on that you have my whole-hearted support...but
prohibiting perfectly logical and legal things is starting to try to
force your own philosophies on others)?
Change the nature of the syntax and I think it all becomes perfectly
clear and totally non-confusing...don't make it a pseudo-opcode with a
mnemonic...turn it into a possible assignment to a running "location
counter" variable ("$" traditionally in Intel assemblers :)...that is,
"$ = 7C00h" rather than "ORG 7C00h"...it's those horrible Plain
English semantics that are causing the problem (tainted by the fact
that "origin" tends to be time-based in the real-world so, sure, it
_doesn't_ make much sense to go backwards in time and change the
"origin" of where your great grandmother was born...from that
perspective, it's quite frankly a ludicrous idea...no wonder everyone
found it confusing and wanted to throw it out :)...
Another example use; With structure support (still an issue with NASM,
I know...but the same "trick" could be employed for individual memory
locations, just the structure method does them all in one go :), you
can use "ORG" to overlay a structure on top of system memory
locations...for example, create a structure that's the same as the
BIOS data area and then "ORG 400h" and declare an uninitialised
instance of that structure...stick this all into an include file for
convenience...and, hey presto, refer to memory locations in the BIOS
data area _by name_ rather than address...makes a program more
readable...a handy little example include file to package along to
ease the poor old newbie's life, trying to remember offsets for
everything in system memory areas (in fact, the assembler I saw that
used the "* = $500" style of notation was a C64 assembler and you used
this trick very often to stick data into the various system memory
areas...I/O is memory-mapped and kernel memory areas, you see, are
exposed so it was a very handy trick indeed...not so useful on modern
OSes, granted, because they don't like or use fixed memory locations
anymore...but DOS and the BIOS are still "old-skool" that it could be
a handy feature, possibly :)
NASM already has some odd "location counter arithmetic"...would it be
unthinkable to simply allow a dynamic re-assignment to "$" to move it
somewhere else?
Beth :)
Beth
> I provided an example at the time, as I recall. The assembly
language
> version of eforth, which was a simple Forth implementation available
on
> the web for years, uses such a mechanism to build the Forth
dictionary
> which traditionally starts from high memory and builds down toward
the
> user's space. Any such statically created data structure or code
will
> have the same problem, if the intent is to have the memory space
used
> starting from high addresses.
Ooh, yes, of course..."upside-down" memory is really going to throw
this weird "chronological" concept on its head...literally...if it's
"upside down" this strange abstract "time" idea on "ORG" completes its
weirdness full circle...some structures are "upside-down" so this very
weird idea of applying "time" to memory makes no sense for data
structures where "time" runs backwards...
If this whole idea of "time" being applied to memory sounds weird
then, good, it _should_...but, think about it, that's exactly what
you're saying in not allowing "ORG" to go backwards or allowing
multiple ORGs...you're saying "this code _MUST_ be
chronological"...the fact that the CPU runs code "forwards" is
clouding your judgement...memory actually has no true implied
"direction" to it at all...stacks and other "upside-down" data
structures (or switching the direction bit for string operations :)
clearly demonstrate that...there's a _bias_, surely, as humans
expected numbers to _go up_ so that's why the CPU goes in this
direction...but it's not a "real" thing or true hardware limitation...
You're letting yourself be confused by the _name_ "ORG" into thinking
"origin = something in the past = you can't change the past = multiple
origins makes no sense = my great grandfather can't suddenly come from
Poland rather than Sweden"...so, throw out the name "ORG" and think "$
= 5000h" instead...of course the assembler can arbitrarily pop data in
any old location (conventions of the executable loader accepted and
excepted)...this isn't English "origin" which has "time"
included...this is mathematical origin which doesn't...
The end result is a memory image - a big chunk of data - in a file
that the loader loads...it matters not a bean what order those bytes
were written, as the _whole process_ is over by the time it actually
executes...are we accidentally confusing "location counter" for
"program counter" here? Well, watch that...they are quite
different...the program counter follows branches, the location counter
does not...they are _NOT_ both measuring "time" in program execution
terms...
Mind you, NASM has "absolute" which could cover some of these
situations so perhaps it's fine as it is...regular NASM users will
complain, no doubt, if it isn't :)
Beth :)
Alex McDonald
Backwards/forwards applies equally to points on a line without refernce to
time; the analogy with time is a little confusing.
Macros as you describe, stored in libraries, have been around since the
sixties. Multiple passes are essential in decomposing the problem of
assembly/compilation into consistently logical chunks; and yes, memory
limitations forced early compiler writers to physically break out into
multiple passes. But any modern compiler has at least 3 "passes"; a macro
expansion/lexing phase, sometimes separate; a parsing phase and tree
building phase, that describes the program in an internal format; and a code
generation phase. The linker is yet another pass...
The reasons are not shortage of resource, but convenience, maintainability,
retargetability and the support of macro libraries to name but a few.
===snipped
This was a feature in IBM 360 assembler; it was called a DSECT (dummy
section) that built no initialised data or code, but provided a template to
map over memory.
>
> NASM already has some odd "location counter arithmetic"...would it be
> unthinkable to simply allow a dynamic re-assignment to "$" to move it
> somewhere else?
>
> Beth :)
>
>
A pseudo-opcode (directive) has the advantge that you can label it, as in
LABEL ORG 1234
and the same syntax that supports other directives and code parsing
suffices.
I'd recommend to NASM developers taking a look at some older, non-x86
assemblers such as IBM's assemblers; they have been refined over many years
and tested in large commercial developments, and the ideas are well worth
copying.
--
Regards
Alex McDonald
Ed Beroset
> Ed Beroset wrote:
>
>> To my understanding vstart and start are only available if you're
>> assembling directly to a BIN output.
>
>
> True. This applies to "org" also, so it really isn't suitable for what
> Chuck wants - assuming he'd want it in other than binary format.
>
>> That doesn't really meet the need, but I guess I've already said all
>> this already.
>
>
> What about "absolute"? (when it's working)? That will only allow "resb",
> etc., so it wouldn't be any good for "backing up" over data or code, but
> I think it will reserve labels like Chuck's example.
Maybe, but it has limitations. "Absolute" results in nothing emitted to
the output object which is the most serious limitation!
>> BTW, I just looked in the docs for the explanation of vstart and it
>> seems to be missing. If you understand how it actually works (I'm not
>> sure I do) then you might want to capture that in the nasm docs before
>> you forget. If you want, I can help with that.
>
> All we currently say about "vstart" is:
>
> \b Sections can be given a virtual start address, which will be used
> for the calculation of all memory references within that section
> with \i\c{vstart=}.
>
> I'm not sure just what we *ought* to say... any ideas?
At the heart of it, there are a few related but different issues.
1. address within output object code
2. address at runtime
3. allocation versus definition
If I'm writing a boot loader, I would need to put the block signature
55AAh at the end of the code. That requires that I be able to control
the address in sense #1. I also might be writing code which gets
relocated in memory after loading. For instance, it might be option ROM
code that I decompress to RAM before executing. That code must be
generated by the assembler to run at a certain address (or to allow for
address fixups, as with OMF and other formats). In another case, maybe
I'm referring to video memory at A000:0 within my code. To do that I
might wish to describe the structure of memory there but NOT have it
actually be put into my output object code because it either already
exists when my code runs or my code creates it at runtime. In that
case, I want to have a *definition* without any allocation. It's the
same differentiation as resb versus db.
Note that all of these have uses for ANY output format, so it doesn't
make any sense that they'd be restricted to only one. My preference
would be to write the help docs first and THEN code, but that's just me.
I don't understand enough about what start and vstart are intended to do
to be able to explain them. What I *could* write is an explanation of
why you'd want to do some of the things I mentioned above, with
examples. Then I'd leave it to someone who understand the vagaries of
NASM's mechanisms to explain how to do those things with NASM syntax.
> We apparently
> need to better document how to get mapfiles out of it, too.
I think that section 6.1.4 Map files probably explains that sufficiently
and says that only bin files can produce map files. This isn't great,
but it's OK, IMHO, because there are tools for the other formats OMF,
COFF, ELF, which would allow a user to generate a map file from the ojbect.
> It's
> evidently not clear that this is a directive to put in the file, not a
> command-line option as it would be to a linker. Or maybe it should be a
> command-line option... I don't really like introducing a command-line
> option that only applies to one output format. I dunno...
It can be simulated as a command line option.
First, create a file called map which has these three lines:
%ifdef maptype
[map maptype mapfile]
%endif
Then you can use a syntax like this:
nasm -fbin -lfoo.lst -dmapfile=foo.map -pmap foo.asm
-pmap defines the macro above only if mapfile has been defined, so
that's what the -dmapfile=foo.map does. The way NASM currently works,
if maptype is not defined, it will be interpreted as though it were
defined as "all". Other valid values for maptype are brief, sections,
segments, or symbols as documented in the existing help. If you wanted
only segments, for example, you'd do this:
nasm -fbin -lfoo.lst -dmapfile=foo.map -dmaptype=segments -pmap foo.asm
It's not something I use, but maybe somebody else will find it useful.
Ed
C
[snip]
Actually the assembler could do far more that just that: what is to
stop the assembler itself deciding 'that procedure is called only
once and is not public therefore I will inline it' or 'that procedure
is only a few bytes long -- inlining time'. As a result cascades of
automatic inlines could generate very efficient object code out of
still quite readable source. (Of course a compiler option or syntax
construct to either stop inlining or force inlining would be needed.)
Current process (compiler - assemblers may be a bit simpler):
read file -> tokenise -> parse / generate AST -> analyse AST ->
generate code -> generate library -> link libraries -> executable
I think the 'link libraries' should preceed the 'generate code', being
merged into the 'analyse AST' stage (which could also strip dead code).
Any libraries could be read in during the parse stage (as soure code,
we have enough memory now) or during the analyse stage as preparsed
ASTs (which could be manupulated much easier than binary libraries).
Also the code in the AST could be reordered much more easily than
that in a binary library, making inlining procedures almost trivial.
What I would really like to see an assembler with the ability to inline
code into an inlined macro. Something of the ilk...
; defining the macro ...
macro loop <times, .inline code>
mov ecx, times
@@lp:
.inline code
sub eax, 1
jnz @@lp
endm
; using the macro ...
copyPage:
; esi -> src, edi -> dest
loop 4096 / 8, {
mov eax, [esi]
mov ebx, [esi+4]
add esi, 8
mov [edi], eax
mov [edi+4], eax
add edi, 8
}
ret
The macro would be inlined into the procedure and part of the
procedure (between '{' and '}') would be inlined into the macro.
This should be excellent for implementing HLL style control
structures.
> of doing things because RAM sizes were crap in the late
> summer of 1953 or whatever...and no-one has been bothered to
> reconsider things with the abilities of modern hardware that _can_
> load GBs of data into virtual memory (perhaps even _physical RAM_
> these days, as 1GB RAM isn't at all unheard of :)...and doesn't need
> to do all that "multiple pass" / "phased tool chain" nonsense for
> hardware limitation reasons any more...
Yup. Though I think all this could be done with only a few Mb.
> Of course, to get around this requires a total redesign of tools to
> throw out the whole "tool chain" concept as it currently stands or to,
> like C++ compilers do with "inline" functionality, "cheat" by stuffing
> extra information into object code...
They could achieve the same result by reversing the compile AST and
link stage in the tool chain, as mentioned above.
> Ironically, I'm agreeing with Rene's "one tool" concept but actually
> _because_ I want multiple file modularity and so forth...
In some ways I agree with him too; binary libraries have been around
so long that people often fail to see the limitations inherent in
their utilisation.
[snip]
C
2003/8/24
arargh3...@now.at.arargh.com
<alex...@btopenworld.com> wrote:
<snip a lot>
>A pseudo-opcode (directive) has the advantge that you can label it, as in
>
>LABEL ORG 1234
>
>and the same syntax that supports other directives and code parsing
>suffices.
>
>I'd recommend to NASM developers taking a look at some older, non-x86
>assemblers such as IBM's assemblers; they have been refined over many years
>and tested in large commercial developments, and the ideas are well worth
>copying.
Especially the macro facilities. Remember, most of the SYSGEN process
was one large macro assembly.
Alex McDonald
<arargh3...@NOW.AT.arargh.com> wrote in message
news:c5cikv8kqm9bqphdr...@4ax.com...
> On Sun, 24 Aug 2003 11:17:25 +0000 (UTC), "Alex McDonald"
> <alex...@btopenworld.com> wrote:
>
>
> <snip a lot>
> >A pseudo-opcode (directive) has the advantge that you can label it, as in
> >
> >LABEL ORG 1234
> >
> >and the same syntax that supports other directives and code parsing
> >suffices.
> >
> >I'd recommend to NASM developers taking a look at some older, non-x86
> >assemblers such as IBM's assemblers; they have been refined over many
years
> >and tested in large commercial developments, and the ideas are well worth
> >copying.
>
> Especially the macro facilities. Remember, most of the SYSGEN process
> was one large macro assembly.
I remember all too well. Early version CICS terminal tables and TCAM...
shudder. Great macro facilities, though.
>
> --
> Arargh308 at [drop the 'http://www.' from ->] http://www.arargh.com
> BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
>
> To reply by email, remove the garbage from the reply address.
>
--
Regards
Alex McDonald
Frank Kotler
> [ Then you'd glad that I _wasn't_ in those discussions, they would
> have gone on for years and years :) ]
Yes.
....
> Read my other posts here on this matter, Frank...
I have, and you provide a good example of the kind of confusion
introduced by allowing more than one "org". I was leaning strongly
towards "only one", anyway, and you've completely persuaded me that
allowing more than one "org" was an extremely bad idea, and that it
would be a mistake to re-introduce it.
The "origin" is where Nasm starts assembling your code, simple as that.
It's related to "place" - memory location - not to chronology. We don't
need to get into the space-time continuum, parallel multiple universe
theories, or where your grandfather was from.
You lay out one of the ways people want multiple "org"s to work - like
Masm/Tasm, and like Nasm worked between versions 0.98.08 and 0.98.34
(before the mistake was corrected). You want to use "org 7C00h" at the
beginning of your bootsector, and then "org 7DFEh" before the signature.
You expect your assembler to pad to 7DFEh, not simply set the location
counter to that value. Do you expect the "org 7C00h" to also pad to
7C00h? You want it to pad one time, but not the other, right? Good
language design?
As an alternative to the "times" expression (which says precisely what
you want to do), Nasm will now let you:
org 7C00h
section .text
jmp short overbpb
nop
db 'ChaOS '
db 200h
....
overbpb:
....
blackhole:
hlt
jmp short blackhole
section bootsig start=7DFEh
dw 0AA55h
If you really want it like Masm/Tasm, stick with 0.98.34...
Other people want/expect a second "org" to set the location counter to
the new value, but without padding or otherwise altering the disk file.
This is useful if you want to move code/data from where it's loaded to
some other location before it's executed. "section foo vstart=9000h"
will do that. "start" pads, "vstart" doesn't.
> .code
>
> _start: call InitVideo
>
> ...
>
> call FreeVideo
>
> call ExitProcess, eax
>
> ---------------------------
; initvideo.asm
mov ax, 13h
int 10h ; well, not in 32-bit code... :)
;-----------------
; freevideo.asm
mov ax, 3
int 10h
;-----------------
; myprog.asm
_start:
%include "initvideo.asm"
; ...
%include "freevideo.asm"
; ...
push 0
call ExitWindows ; (I mean ...Process :)
You'd need a little more than that to tell Nasm you want a 32-bit
segment (assuming you do), but no multiple "org"s.
> Hey, if you've got a bit of rebellious streak in you, why not suggest
> that, instead, "*" stands for the location counter and that something
> like "* = $1000" (found on some non-Intel assemblers as their version
> of "ORG"...NASM accepts "$" as a hex prefix, yes? Does it also
> recognise "$" as the location counter value?
Yes, and this might be a sensible, "intuitive" way to move the location
counter - which is really not the "origin". Currently it's "read-only"
(I think). The question still arises, do you expect it to pad or not?
....
> Some other examples; If you're allowing conditional assembly then it's
> quite useful to allow going backwards in the code too...define a chunk
> of memory with "default" values...it hits a conditional block which
> then "backtracks" and inserts different "non-default" values based
> upon addresses of things later on in the code (the actual condition
> only being calculable at that later point in the code so you've no
> option but to "backtrack"...you can't "force" it to be
> "chronological", whether you like it or not :)...a totally
> "non-chronological" operation...why disallow it?
I really don't see that this makes any sense at all. What Chuck was
talking about, going "backwards" and assigning new names to areas of
memory which already have names makes perfect sense. What Ed was talking
about - filling memory from the top down - makes sense. Nasm doesn't
have a nice (if any?) way to do that, and perhaps it should. *This*
actually might be a case where multiple "origins" might make sense. If
you start to assemble code at 100h, you can't "start" at some higher
value, but it might make sense to "start" at 0FFFFFFF0h, and then "back
up" and "start again" at 0FFFFFFE0h. I still don't think "org" is the
best name for it. But I can't imagine why you'd need to assemble the
"wrong" code or data, and then back up and overwrite it. Makes sense to
do it at run time, of course, but I don't see the use of doing it at
assembly time.
> Heck, this is _assembly_...why disallow _anything_?
I look forward to the tool that supports numbers in random order, rather
than forcing them into the fascist "1, 2, 3, ..." convention :)
> ...no wonder everyone
> found it confusing and wanted to throw it out :)...
No one wanted to throw it out. We wanted it to mean exactly one thing.
> Another example use; With structure support (still an issue with NASM,
> I know...but the same "trick" could be employed for individual memory
> locations, just the structure method does them all in one go :), you
> can use "ORG" to overlay a structure on top of system memory
> locations...for example, create a structure that's the same as the
> BIOS data area and then "ORG 400h" and declare an uninitialised
> instance of that structure...stick this all into an include file for
> convenience...and, hey presto, refer to memory locations in the BIOS
> data area _by name_ rather than address...
Perfectly possible with Nasm 0.98, or current Nasm.
struc bda
padding resb 400h
bda_com0 resw 1
bda_com1 resw 1
....
endstruc
We're just assigning numbers to labels here, the "resb 400h" isn't going
to take up any space. Personally, I'd probably leave it out and
reference data from a segreg of 40h, but you could do it either way. And
you can put this in a separate file and include it, if you like. No new
"origin" required.
> (in fact, the assembler I saw that
> used the "* = $500" style of notation was a C64 assembler and you used
> this trick very often to stick data into the various system memory
> areas...
It's not clear to me what the binary output from this - or the loader
for it - would look like.
> NASM already has some odd "location counter arithmetic"...
What location counter arithmetic do you consider "odd"?
> would it be
> unthinkable to simply allow a dynamic re-assignment to "$" to move it
> somewhere else?
No. Details of just how this re-assignment should work are unclear.
Using "org" to mean both the origin - where the assembler is to start
assembling - and the location counter - where the assembler is
assembling now - is what strikes me as... well, "thinkable" - we did it
for a while - but ultimately a bad idea.
All of this (except the bda structure) applies only in binary output
format. I'm not sure what...
section data
org 1234h
msg db "hello world", 0
.... would be expected to communicate to the linker if done in a linkable
object format. I don't know enough about linkers to know if that's
something Nasm could force, or if it would have to be done with a
"linker script"...
In any case, one origin per file seems right to me. Pity it *isn't*
about chronology - if we had a "jmp -10 milliseconds" instruction, we
could write *wicked* fast code! :)
Best,
Frank
Ed Beroset
> Beth wrote:
>> Hey, if you've got a bit of rebellious streak in you, why not suggest
>> that, instead, "*" stands for the location counter and that something
>> like "* = $1000" (found on some non-Intel assemblers as their version
>> of "ORG"...NASM accepts "$" as a hex prefix, yes? Does it also
>> recognise "$" as the location counter value?
>
>
> Yes, and this might be a sensible, "intuitive" way to move the location
> counter - which is really not the "origin". Currently it's "read-only"
> (I think). The question still arises, do you expect it to pad or not?
That's easy: never ever pad. If a programmer wants it padded, her or
she can use "times." However, start, vstart need to be available for
other-than-bin formats for it to be possible to do the kinds of
operations that Chuck Crayne and I have mentioned.
Ed
Frank Kotler
> That's easy: never ever pad. If a programmer wants it padded, her or
> she can use "times."
True, that's easy, but programmers appear not to *want* to use "times".
That's what it's there for (among other things), but there's a
resistance to using it.
> However, start, vstart need to be available for
> other-than-bin formats for it to be possible to do the kinds of
> operations that Chuck Crayne and I have mentioned.
Well, maybe not "start" and "vstart"... I think for what Chuck's example
requires, "absolute" should work. Your example involves actually
assembling data (code, too?) at some address - can we consider "top of
memory" to be known at assemble-time? I suppose 0FFFFFFFFh? Or are we
interested in physical memory? Anyway, "absolute" won't allow you to
assemble code or data, so it's no good.
In another post (hope you don't mind me combining replies), you say:
> At the heart of it, there are a few related but different issues.
> 1. address within output object code
> 2. address at runtime
> 3. allocation versus definition
>
> If I'm writing a boot loader, I would need to put the block signature
> 55AAh at the end of the code. That requires that I be able to control
> the address in sense #1.
Right. In "bin" format, we've got this covered with "start" (although it
pretty much duplicates what you could do with "times"). Is this
something we might want to do in a linkable format?
> I also might be writing code which gets
> relocated in memory after loading. For instance, it might be option ROM
> code that I decompress to RAM before executing. That code must be
> generated by the assembler to run at a certain address (or to allow for
> address fixups, as with OMF and other formats).
In "bin" format, "vstart" will do that. For "obj" (OMF) format, the
manual says:
-----------------
The obj file format also allows segments to be declared as having a
pre-defined absolute segment address, although no linkers are currently
known to make sensible use of this feature; nevertheless, NASM allows
you to declare a segment such as SEGMENT SCREEN ABSOLUTE=0xB800 if you
need to. The ABSOLUTE and ALIGN keywords are mutually exclusive.
------------------
Doesn't sound hopeful, unless there *are* linkers that "make sensible
use" of it... The "win32" format adds this intriguing bit:
------------------
info defines the section to be an informational section, which is not
included in the executable file by the linker, but may (for example)
pass information to the linker. For example, declaring an info-type
section called .drectve causes the linker to interpret the contents of
the section as command-line options.
-------------------
I believe some linkers *will* allow you to specify the location of a
section on the command-line, so maybe this could be useful(?). (might
make it possible to implement an "inclib" directive in win32, too...)
Other output formats don't seem to support anything useful.
> In another case, maybe
> I'm referring to video memory at A000:0 within my code. To do that I
> might wish to describe the structure of memory there but NOT have it
> actually be put into my output object code because it either already
> exists when my code runs or my code creates it at runtime. In that
> case, I want to have a *definition* without any allocation. It's the
> same differentiation as resb versus db.
"absolute" should do that - I'm not sure how it would work on the
"segment part". Unfortunate that it was one of the bugs in 0.98, so no
one could use it! ("absolute 0", which "struc" depends on, worked,
"absolute somelabel" didn't) Actually assembling code or data at a fixed
address is the tough one.
> Note that all of these have uses for ANY output format, so it doesn't
> make any sense that they'd be restricted to only one. My preference
> would be to write the help docs first and THEN code, but that's just me.
We came as close to that with the new multisection support for the bin
format as we've come with anything - wrote a "specification" first, at
least. Seems not to have helped much... We still committed a serious
"thinko" by making "org", "start", and "vstart" *signed* integers, and
no one noticed until *after* the code was released (it'll be fixed in
the next release). I agree with the mechanism, though. For my *own*
code, I just start coding and see what it turns out to be. That won't
work when we know it's supposed to be Nasm :)
> I don't understand enough about what start and vstart are intended to do
> to be able to explain them.
The short answer would be that "start" is for #1 above, "vstart" is for
#2. There may be more to it than that...
> What I *could* write is an explanation of
> why you'd want to do some of the things I mentioned above, with
> examples. Then I'd leave it to someone who understand the vagaries of
> NASM's mechanisms to explain how to do those things with NASM syntax.
You've given us a couple above - if you've got more, trot 'em out! I
understand how to do the things you mentioned in bin format. If there's
a way to do 'em in linkable object formats, maybe we can figure it out -
or figure out what Nasm would need, to be able to.
>> We apparently need to better document how to get mapfiles out of it,
too.
> I think that section 6.1.4 Map files probably explains that sufficiently
> and says that only bin files can produce map files. This isn't great,
> but it's OK, IMHO, because there are tools for the other formats OMF,
> COFF, ELF, which would allow a user to generate a map file from the
ojbect.
Yeah. Will other assemblers produce a map file? I think of that as being
something the linker does. Maybe something to think about for the future...
> It can be simulated as a command line option.
>
> First, create a file called map which has these three lines:
>
> %ifdef maptype
> [map maptype mapfile]
> %endif
>
> Then you can use a syntax like this:
>
> nasm -fbin -lfoo.lst -dmapfile=foo.map -pmap foo.asm
Cool! I hadn't thought of using "-p" for this purpose (in fact, I don't
think I've ever used it for any purpose). There really ought to be a
supplement to the manual with examples like this. Maybe someday...
Best,
Frank
Beth
> Beth wrote:
> > [ Man, and I thought it was dumb that macros and procedures in
most
> > substandard way (either worse performance or making source code
less
> > readable :)
>
> Actually the assembler could do far more that just that: what is to
> stop the assembler itself deciding 'that procedure is called only
> once and is not public therefore I will inline it' or 'that
procedure
> is only a few bytes long -- inlining time'. As a result cascades of
> automatic inlines could generate very efficient object code out of
> still quite readable source. (Of course a compiler option or syntax
> construct to either stop inlining or force inlining would be
needed.)
>
> Current process (compiler - assemblers may be a bit simpler):
> read file -> tokenise -> parse / generate AST -> analyse AST ->
> generate code -> generate library -> link libraries ->
executable
Of course, this is a possibility...but, in the spirit of ASM, I'm
specifying that it's done manually...nothing going on "behind your
back"...
Indeed; Such things are far from inconceivable...my simple
requirements, though, stick to the spirit of "nothing going on behind
your back" ASM...this is a case of allowing "inline" to be specified
manually...it _could_ all be automated but that's not my intention
here...merely to allow the facility for it to be done
first...thereafter, debates can rage over whether such "behind your
back evilness" should be provided with some command-line switch :)
> > of doing things because RAM sizes were crap in the late
> > summer of 1953 or whatever...and no-one has been bothered to
> > reconsider things with the abilities of modern hardware that _can_
> > load GBs of data into virtual memory (perhaps even _physical RAM_
> > these days, as 1GB RAM isn't at all unheard of :)...and doesn't
need
> > to do all that "multiple pass" / "phased tool chain" nonsense for
> > hardware limitation reasons any more...
>
> Yup. Though I think all this could be done with only a few Mb.
Indeed; But stressing GBs are a possibility on modern hardware
emphasises the point sufficiently..."ad absurdum"...or, in modern
parlance, stressing the absurdity with use of some "overkill" ;)
> > Of course, to get around this requires a total redesign of tools
to
> > throw out the whole "tool chain" concept as it currently stands or
to,
> > like C++ compilers do with "inline" functionality, "cheat" by
stuffing
> > extra information into object code...
>
> They could achieve the same result by reversing the compile AST and
> link stage in the tool chain, as mentioned above.
Oh, there's hundreds of different possible ways it could be done...in
fact, that is the underlying point...there's a world of possibilities
out there and modern hardware that has unleashed totally unimaginable
things from back in the 1950s as quite mundane, "boring"
operations...yet, it's all still stuck in the past...
Now, imagine a word processor that wasn't WYSIWYG but where you typed
in special "command" tags into the ASCII text stream...and then, once
completed, you'd "compile" the text and see if you made any mistakes
with the tags...if it compiles, great...now it's time to "link" it to
the exact printer driver you've got so you can print it out...only at
this point - printing it out - do you actually get to see if you were
on the right track with your "tags"...if not, back to the drawing
board...that is, going through this whole edit / compile / link
process again and again until it's right...
Imagine that word processor - not unlikely prior to WYSIWYG GUIs - and
then ask why such tools have clearly moved on far beyond such a simple
model but programmers - who ironically write these word processors -
still use this whole "fingers crossed" process...
Another way to look at it is: Machines are able to seamlessly
multi-task and following a set order of instructions their bread and
butter...humans focus on only one or two tasks normally, are creative
and not following orders are where our skills above the machine
shine...yet, in the tool chain notion, the human has to follow a set
order and open multiple windows and run multiple tools and keep track
of multiple things...while the machine is given single straightforward
tasks and only one "instruction" at a time...it's the wrong way
round...humans are being made to do jobs machines excel at
doing...that's just ever-so-slightly twisted, really :)
> > Ironically, I'm agreeing with Rene's "one tool" concept but
actually
> > _because_ I want multiple file modularity and so forth...
>
> In some ways I agree with him too; binary libraries have been around
> so long that people often fail to see the limitations inherent in
> their utilisation.
Note that "one tool" in Rene's view probably excludes DLLs but it
wouldn't in mine...so, sure, modularise it all and have it that
different "front end" and "back end" DLLs can be loaded as "plug-ins"
and goodness knows what else..."one tool" does not necessarily mean
"one file" or "only one way of using it" or anything else like that...
In a sense, this already exists in a form...HLA automatically goes
through the tool chain for you, as does GCC, as does MASM...if you
want less, you ask for less with a command switch...clearly, I'm not
completely barking up the wrong tree or these tools would shy away
from this, not endorse it...the difference I'm going further to stress
is that these could all be DLLs...things transferred by memory rather
than temporary files...different interfaces attached (so, "HLA.DLL"
does the actual dirty work and "HLA.EXE" is merely the command-line
interface that interprets the command-line, loads the DLL supplying
its duties and interprets the output to provide user readable
messages...better yet, you could then have localised versions of
"HLA.EXE" for English, French, German, etc. but all use the exact same
"HLA.DLL" assembler...even more, an IDE that wants to support HLA
doesn't have to battle with creating command-lines and then trying to
decode the ASCII output...it loads the DLL, uses it and interprets the
return codes, translating that into whatever suits the interface...it
would be more modular, more flexible, faster, encourages third-party
interfaces to be attached so that IDEs can have some pretty impressive
integration with the tool, etc., etc....this stuff is hardly rocket
science - as other applications do this sort of thing all the time -
yet is not being considered because of a heck of a lot of "stuck in
the mud" thinking about the "purity" of 1950s tool ideas or some such
:)...
Beth :)
Alex McDonald
> Now, imagine a word processor that wasn't WYSIWYG but where you typed
> in special "command" tags into the ASCII text stream...and then, once
> completed, you'd "compile" the text and see if you made any mistakes
> with the tags...if it compiles, great...now it's time to "link" it to
> the exact printer driver you've got so you can print it out...only at
> this point - printing it out - do you actually get to see if you were
> on the right track with your "tags"...if not, back to the drawing
> board...that is, going through this whole edit / compile / link
> process again and again until it's right...
>
No need to imagine; just use Forth.
--
Regards
Alex McDonald
Beth
> Beth wrote:
> > Now, imagine a word processor that wasn't WYSIWYG but where you
typed
> > in special "command" tags into the ASCII text stream...and then,
once
> > completed, you'd "compile" the text and see if you made any
mistakes
> > with the tags...if it compiles, great...now it's time to "link" it
to
> > the exact printer driver you've got so you can print it out...only
at
> > this point - printing it out - do you actually get to see if you
were
> > on the right track with your "tags"...if not, back to the drawing
> > board...that is, going through this whole edit / compile / link
> > process again and again until it's right...
>
> No need to imagine; just use Forth.
Hehehe...except, surely, this cannot be true...as the omniscient Sage
has already confirmed the universal truth that FORTH is the ultimate
language, complete in its exclusive membership as _the_ programming
language for coming Utopia of Sage's eternal wisdom...
Well, something like that...to be honest, his ego did lose me along
the way and I'm having to infer the implications of some of this :)
Anyway, the humour is fully appreciated that I don't mean to diminish
it by pointing out the serious fact that _even FORTH_ has interpreted
versions - akin to BASIC - which breaks out of the usual cycle toward
a more seamless development process...
Unintentionally, debuggers with assemble / disassemble functionality
can coincidentally be used very loosely in such a manner...but the
environment isn't designed for this exclusively...it's a coincidence
so it doesn't do it very well...but those who've used DEBUG and other
debuggers in this capacity will appreciate the basic notion of what
I'm driving at...
An environment where the _needs of the development_ drive the
process - things can occur "out of order" as befits what _needs to be
done_ - rather than the technicalities of making the tools easier to
code rules the roost...this is clearly a _major_ tool difference
between ASM and HLLs...it's the development they followed that ASM
avoided and fell behind with...
Ignoring the _details_ of what Delphi / C++ Builder / Kylix
development is _visually_ and concentrating on what it is from a
development point of view, then the step it takes is to _fuse_ the
"stages" of the development cycle together seamlessly...BASIC
interpreters, for decades, have employed environments where the
technicalities of the compilation process are hidden...in QuickBASIC,
for an example, there is no notion of any "phases" to be
followed...code is typed (tokenised as typed) and any further
processing is hidden in the "run" command...the immediate mode allows
individual functions to be tested in an interpretative manner...press
F6, type "Function(6)" and see the results...
That is essentially why these environments are considered a lot more
productive and user-friendly and what-not...C / C++ does actually fall
into ASM's bracket on this usually...but this has always been smoothed
over with IDE integration so that though there are "phases" going on,
there's no need to be vastly concerned with it...IDEs try to bolt on
what should be in the tool core itself...MAKE similarly hides the
details...
Of course, this is ASM...the processes should be exposed and precisely
controllable...but that doesn't actually mean that they have to be
thrust into your face with the constant reminder of having to open a
window here and a window there...type and re-type command
lines...tools opened all over the desktop...and everything going
pear-shaped if you accidentally run things out of order...ooh, that
sin of sins to be punished by eternal damnation...
In fact, ASM could steal a march on HLLs here, in that it's always
lipservice in IDEs...tools _founded_ on such notions - such as what
I've been saying about incremental as-you-type compliation - with all
the same bells and whistles but properly _integrated_...well, if you
want "assembly rebirth", there's the gap by which for ASM to burst its
way back to the surface...when tool support is actually _better_ than
HLLs and honed specifically for developing large projects with _fast_,
seamless development...the myths about ASM would be blown out of the
water...
Oh, well...to dream, perchance to finally be able to sleep as the work
is eventually done...eh? ;)
Beth :)
Alex McDonald
> Alex McDonald wrote:
> > Beth wrote:
> > > Now, imagine a word processor that wasn't WYSIWYG but where you
> typed
> > > in special "command" tags into the ASCII text stream...and then,
> once
> > > completed, you'd "compile" the text and see if you made any
> mistakes
> > > with the tags...if it compiles, great...now it's time to "link" it
> to
> > > the exact printer driver you've got so you can print it out...only
> at
> > > this point - printing it out - do you actually get to see if you
> were
> > > on the right track with your "tags"...if not, back to the drawing
> > > board...that is, going through this whole edit / compile / link
> > > process again and again until it's right...
> >
> > No need to imagine; just use Forth.
>
> Hehehe...except, surely, this cannot be true...as the omniscient Sage
> has already confirmed the universal truth that FORTH is the ultimate
> language, complete in its exclusive membership as _the_ programming
> language for coming Utopia of Sage's eternal wisdom...
>
> Well, something like that...to be honest, his ego did lose me along
> the way and I'm having to infer the implications of some of this :)
I'm not up to speed on your opinion of his opinion, nor his of yours. I
presume that you don't see eye to eye. Forth can't be an exclusive club; I
am a member.
>
> Anyway, the humour is fully appreciated that I don't mean to diminish
> it by pointing out the serious fact that _even FORTH_ has interpreted
> versions - akin to BASIC - which breaks out of the usual cycle toward
> a more seamless development process...
Perhaps the humour is caused by a misunderstanding. Forth (note the case) is
both an interpreter and a compiler at the same time, and offers a highly
interactive environment. For example, Win32Forth (a Forth for Windows, as
the name suggests) includes an x86 assembler, editor, classes/objects and
full Windows support. All in an interactive environment and several orders
of magnitude faster than an interpreter. There's no need for
edit/compile/test cycles.
===snipped
>
> In fact, ASM could steal a march on HLLs here, in that it's always
> lipservice in IDEs...tools _founded_ on such notions - such as what
> I've been saying about incremental as-you-type compliation - with all
> the same bells and whistles but properly _integrated_...well, if you
> want "assembly rebirth", there's the gap by which for ASM to burst its
> way back to the surface...when tool support is actually _better_ than
> HLLs and honed specifically for developing large projects with _fast_,
> seamless development...the myths about ASM would be blown out of the
> water...
>
Exactly what Forth does. But when you need HLL constructs, they're there for
you too.
> Oh, well...to dream, perchance to finally be able to sleep as the work
> is eventually done...eh? ;)
"Right in the selfsame form, showed Forth to all men's sight". Same author.
> Beth :)
>
>
--
Regards
Alex McDonald
C
> C (the voice of reason) wrote:
[snip]
> > The macro would be inlined into the procedure and part of the
> > procedure (between '{' and '}') would be inlined into the macro.
> > This should be excellent for implementing HLL style control
> > structures.
>
> Indeed; Such things are far from inconceivable...
[obviously, as I just conceived it :-)]
> my simple requirements, though, stick to the spirit of "nothing
> going on behind your back" ASM...this is a case of allowing
> "inline" to be specified manually...
Of course. A command line option to enable the optimisation.
> it _could_ all be automated but that's not my intention
> here...merely to allow the facility for it to be done
> first...thereafter, debates can rage over whether such "behind
> your back evilness" should be provided with some command-line
> switch :)
Yup, thats one of the things I am working on.
[snip]
> Another way to look at it is: Machines are able to seamlessly
> multi-task and following a set order of instructions their bread and
> butter...humans focus on only one or two tasks normally, are creative
> and not following orders are where our skills above the machine
> shine...yet, in the tool chain notion, the human has to follow a set
> order and open multiple windows and run multiple tools and keep track
> of multiple things...while the machine is given single straightforward
> tasks and only one "instruction" at a time...it's the wrong way
> round...humans are being made to do jobs machines excel at
> doing...that's just ever-so-slightly twisted, really :)
What I would like is a see a tool which combines some of the features
of an IDE, CVS and compiler/assembler. The IDE would allow you to
edit a single procedure, then you select the [commit] option and it
updates the compiles the procedure and updates the CVS. (Options
to cancel and revert should also be present.) A 'todo' list would
then be presented detailing the procedures and global variables
still needed (this would be similar to an error report, save that
is would only report for the procedure not the entire programme.
Such an IDE would allow several improvements, the compiler would
run in small increments as a background process (maybe with
several attempts using different heuristics and profiling
feedback, some of which would not be available as they are too
slow in a standard compile (being NP complete problems)).
Therefore the edit/compile/debug cycle would be greatly
shortened for simple typo based errors, plus faster compiled
programmes could be generated (or, for assembly, accurate cycle
count estimates displayed)
[If you programme like me, having several source entry windows
open would be a necessary, as simultaneously working in several
interrelated processes is common. Therefore commits should only
be done when requested -- a simple change of window does not
mandate a mini-compile thread should be started.]
This would allow several advantages, not only would the programmer
become quickly aware of simple compile errors while still thinking
in the context of the procedure being edited, but analysis of the
procedures would become easy. At the press of a button a hyper-
linked list of all the variables referenced by the procedure could
be made available. Code and data flow diagrams could be
constructed and displayed (also in hyperlinked form) making the
traversal of large projects quick and simple. Many other goodies
could be added.
In this design, the distinction between cut-and-paste and library
/ black box use would be largely blured, even mixing several languages
on procedure level granularity (depending on their strengths and
weaknesses) would be possible as the compiler exist in several
different parts. Parts for compiling the language and parts for
optimising the generated code. Imagine writing a few lines of a
HLL, pressing commit, and instantly seeing the generated assembly
ready for further hand optimisation -- surely this would be the
best way to pursuade programmers to learn assembly, current HLL
compilers leave them far too insulated from the code generated,
which freqently leaves the programmers ignorant of the machine
level optimisation issues.
The question is, how should such as CASE tool be developed. A
component based approach seems feasable, with small plugin modules
to: compile, profile, analyse, display, hyperlink and do any
other goodies. Maybe this will be my next big project.
[snip]
> Note that "one tool" in Rene's view probably excludes DLLs but it
> wouldn't in mine...so, sure, modularise it all and have it that
> different "front end" and "back end" DLLs can be loaded as "plug-ins"
> and goodness knows what else..."one tool" does not necessarily mean
> "one file" or "only one way of using it" or anything else like that...
I get your point. [Hmm, maybe I should read ahead, I just wrote some
thing similar -- though the idea of much closer integration of
components was what I had in mind, instead of simple automated
makes.]
[snip]
> loads the DLL supplying its duties and interprets the output to
> provide user readable messages...
In my design it would be even more closely integrated than that,
the compiler unit would integrate directly with the error reporting
unit, probably providing only status numbers and the position of
the error. This would save the reporter having to parse the error
message, all that is required is too lookup the message code in
a resource file -- or even better the manual, which could provide
examples of common causes and notes on how to solve the problem.
The multilingual issue, you note below, would be easily resolved
by modifying the manual (would could be available in HTML).
> better yet, you could then have localised versions of "HLA.EXE"
> for English, French, German, etc. but all use the exact same
> "HLA.DLL" assembler... even more, an IDE that wants to support HLA
> doesn't have to battle with creating command-lines and then trying to
> decode the ASCII output...it loads the DLL, uses it and interprets the
> return codes, translating that into whatever suits the interface...it
> would be more modular, more flexible, faster, encourages third-party
> interfaces to be attached so that IDEs can have some pretty impressive
> integration with the tool, etc., etc....this stuff is hardly rocket
> science - as other applications do this sort of thing all the time -
> yet is not being considered because of a heck of a lot of "stuck in
> the mud" thinking about the "purity" of 1950s tool ideas or some such
> :)...
As the first IBM FORTRAN compiler had some 63 stages, we have come some
way since the 50's, though you are right there is much further to go.
Programming tools can not only be improved, the technology is there to
improve them right now.
C
2003/8/29
H. Peter Anvin
By author: Ed Beroset <ber...@mindspring.com>
In newsgroup: comp.lang.asm.x86
>
> > Yes, and this might be a sensible, "intuitive" way to move the location
> > counter - which is really not the "origin". Currently it's "read-only"
> > (I think). The question still arises, do you expect it to pad or not?
>
> That's easy: never ever pad. If a programmer wants it padded, her or
> she can use "times." However, start, vstart need to be available for
> other-than-bin formats for it to be possible to do the kinds of
> operations that Chuck Crayne and I have mentioned.
>
The biggest problem is that then the object format needs to support
it. As far as I know, most only do for *post*-linker output.
Remember, the NASM "bin" format is effectively a linker built into
NASM, for user convenience.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Ed Beroset
> Exactly what Forth does. But when you need HLL constructs, they're there for
> you too.
Actually, there's been a recent thread over on comp.lang.forth about
type safe languages and Forth. My take on things is that when you need
HLL contructs, maybe they're not *quite* there for you in Forth, but
they could be simulated to large degree.
Ed
Ed Beroset
> Followup to: <xQw2b.9769$jY2....@newsread1.news.atl.earthlink.net>
> By author: Ed Beroset <ber...@mindspring.com>
> In newsgroup: comp.lang.asm.x86
>
>>>Yes, and this might be a sensible, "intuitive" way to move the location
>>>counter - which is really not the "origin". Currently it's "read-only"
>>>(I think). The question still arises, do you expect it to pad or not?
>>
>>That's easy: never ever pad. If a programmer wants it padded, her or
>>she can use "times." However, start, vstart need to be available for
>>other-than-bin formats for it to be possible to do the kinds of
>>operations that Chuck Crayne and I have mentioned.
>>
>
> The biggest problem is that then the object format needs to support
> it. As far as I know, most only do for *post*-linker output.
> Remember, the NASM "bin" format is effectively a linker built into
> NASM, for user convenience.
I find virtually no use for NASM's bin format, and that's why things
like vstart, and start would be useful elsewhere. For example, if I
could specify the start addresses of sections of code for OMF output
records, there are a number of tools that would handle that. At the
very least, one could use a standard linker to create a DOS executable
and then postprocess that, but it's not necessary to go through that
intermediate step.
Ed
Frank Kotler
> I find virtually no use for NASM's bin format, and that's why things
> like vstart, and start would be useful elsewhere. For example, if I
> could specify the start addresses of sections of code for OMF output
> records, there are a number of tools that would handle that. At the
> very least, one could use a standard linker to create a DOS executable
> and then postprocess that, but it's not necessary to go through that
> intermediate step.
Okay, I did this...
;-----------------------
; nasm -f obj hwexe.asm
; val(or valx) hwexe.obj
; or alink -oEXE hwexe.obj
; or MS's link hwexe.obj
; or qlink or ???
;-----------------------
section code absolute=1234h ; <-???
...start
mov ax, data
mov ds, ax
mov dx, msg
mov ah, 9
int 21h
exit:
mov ah, 4Ch
mov al, 0 ; errorlevel to return
int 21h
section data
msg db 'hello, world!$'
section my_stack stack
resb 100h
;---------------------
Alink barfed on it, complaining about data emitted to an absolute
segment, but MS's old 16-bit link swallowed it. An attempt to run it
yielded "Program too big to fit in memory" (although the size of the
executable was "normal"). Maybe not appropriate to do this in 16-bits?
How would I try something intelligent (loosely) with this?
Best,
Frank
Beth
> Beth wrote:
> > > No need to imagine; just use Forth.
> >
> > Hehehe...except, surely, this cannot be true...as the omniscient
Sage
> > has already confirmed the universal truth that FORTH is the
ultimate
> > language, complete in its exclusive membership as _the_
programming
> > language for coming Utopia of Sage's eternal wisdom...
> >
> > Well, something like that...to be honest, his ego did lose me
along
> > the way and I'm having to infer the implications of some of this
:)
>
> I'm not up to speed on your opinion of his opinion, nor his of
yours. I
> presume that you don't see eye to eye. Forth can't be an exclusive
club; I
> am a member.
Ah, well...basically, it's just a small joke with the Sage...he said
that the "ultimate language" would allow but a single command to be
entered and it would do everything...and I couldn't resist the
joke...Forth builds up a vocabulary until the _entire program_ is but
one single "verb"...hence, Forth is the ultimate language!!
Of course, that actually wasn't what Sage really meant...but minor
details like that tend never to stop me making bad jokes and playing
silly word games ;)
> > Anyway, the humour is fully appreciated that I don't mean to
diminish
> > it by pointing out the serious fact that _even FORTH_ has
interpreted
> > versions - akin to BASIC - which breaks out of the usual cycle
toward
> > a more seamless development process...
>
> Perhaps the humour is caused by a misunderstanding. Forth (note the
case) is
> both an interpreter and a compiler at the same time, and offers a
highly
> interactive environment. For example, Win32Forth (a Forth for
Windows, as
> the name suggests) includes an x86 assembler, editor,
classes/objects and
> full Windows support. All in an interactive environment and several
orders
> of magnitude faster than an interpreter. There's no need for
> edit/compile/test cycles.
Indeed; And the case thing is just my convention on these things...as
tools like MAKE, for example, are also English words (as is "forth" :)
then to make the distinction clear, I either quote such terms or fully
capitalise them...I always write LINK in text, even if I show a
command line where I type "link" instead...if I'd quoted it instead
(which I probably should have done) then the case would have been
"Forth" instead...I make exception with SpAsm and RosAsm because they
are a weird mixed case affair...that, in itself, is distinction enough
that it's the tool and not the English word "spasm"...but, true
enough, it should probably be "Forth" rather than FORTH in anything I
subsequently write...but, note, I actually wrote it that way because I
used a Forth language many, many moons ago and it was referred to as
"FORTH" in the documentation...address your complaints there, I merely
copied presuming they knew the convention better than I...or perhaps
it used to be FORTH and is now "Forth"...what with longer filenames
and mixed case now being very usual where once not :)
> > In fact, ASM could steal a march on HLLs here, in that it's always
> > lipservice in IDEs...tools _founded_ on such notions - such as
what
> > I've been saying about incremental as-you-type compliation - with
all
> > the same bells and whistles but properly _integrated_...well, if
you
> > want "assembly rebirth", there's the gap by which for ASM to burst
its
> > way back to the surface...when tool support is actually _better_
than
> > HLLs and honed specifically for developing large projects with
_fast_,
> > seamless development...the myths about ASM would be blown out of
the
> > water...
>
> Exactly what Forth does. But when you need HLL constructs, they're
there for
> you too.
Oh, indeed; Forth's philosophy is actually part of the inspiration for
some of my rather mad tool ideas I keep mentioning...although, the
syntax is, well, not wanting to offend, but it's quite "ugly"...so, it
won't look anything like Forth but the whole "vocabulary" stuff I
believe has a great potential in it...I'll keep that philosophical
concept but, well, all that stuff that looks like someone has taken a
big bucket full of punctuation characters and accidentally spilled it
all over the screen...
Or, in short, conserving memory isn't a great concern anymore and
bracketing statements have been demonstrated to be more useful in
studies...so, a bit like how Randy's re-arranged assembly in a
"Pascal-like" syntax, I'm thinking about re-arranging Forth in a
similar way...roughly works the same way but a Pascal or C or whatever
programmer won't have a heart attack just looking at it ;)
> > Oh, well...to dream, perchance to finally be able to sleep as the
work
> > is eventually done...eh? ;)
>
> "Right in the selfsame form, showed Forth to all men's sight". Same
author.
:)
Beth :)
Orlando Llanes
news:SiA3b.22776$8i2....@newsread2.news.atl.earthlink.net...
> I find virtually no use for NASM's bin format, and that's why things
I dunno if you're referring specifically to the bin format, or to a
feature of the bin format in general, but I've used it for some oddball
stuff and plan to use it for an OS :)
One thing I've done with the bin format is create a font to test my
libraries. I also use it to create quick COM programs that I can immediately
debug with TD. I'm currently working on a "Toy" OS where the exe, driver,
and shared library formats are non-standard, so the bin format will be
useful :)
See ya!
Orlando
Alex McDonald
OK, except type safety (although NEON/MOPS objects are much more robust in
that degree). I was thinking of things like IF/ELSE/THEN, DO/LOOP, CASE/OF
and compile time conditionals such as [IF] etc.
--
Regards
Alex McDonald
Beth
> Ed Beroset wrote:
> > I find virtually no use for NASM's bin format, and that's why
things
>
> I dunno if you're referring specifically to the bin format, or
to a
> feature of the bin format in general, but I've used it for some
oddball
> stuff and plan to use it for an OS :)
> One thing I've done with the bin format is create a font to test
my
> libraries. I also use it to create quick COM programs that I can
immediately
> debug with TD. I'm currently working on a "Toy" OS where the exe,
driver,
> and shared library formats are non-standard, so the bin format will
be
> useful :)
I agree; The "bin" option is a great NASM selling point...though not
much use for "normal" activities, it has a wealth of uses for
"oddball" stuff...bootsectors, .com files (no need to link), manually
putting together an MZ executable with custom header (as used in an
example I gave before with making a very small HLA program by using
NASM to create an MZ stub that's only 65 bytes (64 bytes header + 1
byte "ret", just to make it a "valid" MZ program :), which knocks
quite a bit off the size when the default stub pushes the filesize up
by another 4KB page)...OS stuff can greatly make use of it where,
basically, you're not using any of the standard header stuff but
something of your own invention...and so on and so forth...probably
useless for "normal" use (though .com files are "normal" for some
people and "bin" lets you do that without need for a linker :)...but
actually somewhat invaluable for "oddball" uses...to the extent that I
keep NASM handy and always pop it out for this particular feature it
has that no other assembler provides: being able to just spit out the
opcode "as is" into a file without "object code" or EXE2BIN or
executable headers needlessly getting in the way...
Beth :)
Ed Beroset
> "Ed Beroset" <ber...@mindspring.com> wrote in message
> news:SiA3b.22776$8i2....@newsread2.news.atl.earthlink.net...
>
>>I find virtually no use for NASM's bin format, and that's why things
>
>
> I dunno if you're referring specifically to the bin format, or to a
> feature of the bin format in general, but I've used it for some oddball
> stuff and plan to use it for an OS :)
I'm referring to the bin format. Note that I wrote "I find virtually no
use..." and not "The bin format is useless." If *you* find it useful,
that's lovely.
Ed
TS
>use..." and not "The bin format is useless." If *you* find it useful,
>that's lovely.
The .bin format can be pretty handy if you want to create files with
NASM alone without a linker, typically DOS .com or .sys files, but
also any other type of executable or library can be built from
scratch.
Ed Beroset
>>I'm referring to the bin format. Note that I wrote "I find virtually no
>>use..." and not "The bin format is useless." If *you* find it useful,
>>that's lovely.
>
>
> The .bin format can be pretty handy if you want to create files with
> NASM alone without a linker,
What programmer doesn't have at least one linker? I suppose there might
be somebody out there attempting to write software without one, but... why?
Ed
Mark & Candice White
> What programmer doesn't have at least one linker? I suppose there might
> be somebody out there attempting to write software without one, but...
> why?
>
> Ed
A newbie.
Because they have only downloaded NASM and nothing else.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Alexei A. Frounze
>
> > What programmer doesn't have at least one linker? I suppose there might
> > be somebody out there attempting to write software without one, but...
> > why?
> >
> > Ed
>
> A newbie.
> Because they have only downloaded NASM and nothing else.
I'd rather say because they don't yet know the importance of relocating and
the whole issue of code/data relocation. No need to link looks to be a way
to go for many, but as they grow up and mature, they start understanding
what it's all about and what benefits are. Same as structured programming --
you start understanding importance of and need for it through experience by
making more and more complex software. I think this is why.
Get going!
Alex
cLIeNUX user
Why write software with one?
osimplay doesn't have a linker per se. There's an "ELF" word (directive)
that makes an ELF header, but it's quite minimal. There's also a "heap"
word which creates a faux .bss, i.e. unix un-allocated memory, i.e.
uninitialized data, but that's done without even actually using an ELF
.bss section. osimplay ELF programs are one ELF section.
Where a linker starts to look attractive again is when a program gets big,
particularly with an assembler that is a shell script, which is orders of
magnitude slower than e.g. gas. The bootables I'm writing are starting to
develop proto-linker thingies based on concatenating pre-assembled modules
onto the end of the real code. There's a similar phase in the Linux build
process, using "cat". There's no reason to reassemble fonts and so on over
and over when developing an OS, for example. You can keep track of the
offsets to the stuff appended onto the end of something with a simple data
structure declaration at the end of the "live" code. osimplay has the
"clump" word for clumps of offsets. It's a rudimentry "struct".
That's two different types of linking, BTW. One is for the default unix
executable format, the other is for standalone bootables, and neither
requires what one would call a "linker".
Rick Hohensee
>
>Ed
>
Ed Beroset
> humb...@smart.net
>
>>TS wrote:
>>
>>>>I'm referring to the bin format. Note that I wrote "I find virtually no
>>>>use..." and not "The bin format is useless." If *you* find it useful,
>>>>that's lovely.
>>>
>>>
>>>The .bin format can be pretty handy if you want to create files with
>>>NASM alone without a linker,
>>
>>What programmer doesn't have at least one linker? I suppose there might
>>be somebody out there attempting to write software without one, but... why?
>
>
> Why write software with one?
Why drive nails with a hammer instead of a rock?
> osimplay doesn't have a linker per se.
Using a bash shell as an assembler may have been an interesting
intellectual exercise, but you're not seriosuly offering it as a better
way to write software, are you?
Ed
cLIeNUX user
>cLIeNUX user wrote:
>> humb...@smart.net
>>
>>>TS wrote:
>
>Why drive nails with a hammer instead of a rock?
>
Programming is an art. osimplay is a simple toolset. Typical assemblers
are for building huge things that already exist.
>> osimplay doesn't have a linker per se.
>
>Using a bash shell as an assembler may have been an interesting
>intellectual exercise, but you're not seriosuly offering it as a better
>way to write software, are you?
The joke aspect is a distant second in why I did all the work that is
osimplay. I use it, prefer it to C by a wide margin, and do quite
non-trivial things with it.
seedoc of cLIeNUX osimplay (p1 of 9)
osimplay
NAME
osimplay - binary file assembler written entirely in the GNU Bash
shell
PAGE DATE
July 2003
INTERFACE
osimplay filename
after doing
. osimplay
Output is to the created file-variables $output and $listing,
defaulted to ~listing and ~binary.
Individual instructions can be assembled at the shell prompt, since
they are each a shell function. This is after . osimplay, and you may
have to set pass=2, and H=0 or whatever. H is the assembly pointer,
"." in Gas I believe.
DESCRIPTION
In geometry, a point is a degenerate case of a line segment. A point
does not have any properties line segments don't have. A register is a
degenerate case of a stack. A stack is a register with a Z-axis. I
prefer stack machines to register machines, and stack languages to
register machine compilers, but I only have register machines, and
stack languages are at a disadvantage on degenerate hardware. I
therefor wrote the Forthiest register-machine assembler I could
muster. osimplay is Forth in FlatLand.
osimplay is the latest incarnation of shasm, shell assembler. shasm
actually was asmacs first, m4 macros to rename all the INTeL 386
"mnemonics" for Gas. osimplay adds some features of fancier
assemblers, such as rudimentry data structures, and composites for
things that tend to always be used as more than one instruction in a
particular arrangement, such as pattern fills, checksums, min, max and
so on. Some of the names have changed too. MOV was "copy" in asmacs
and shasm, and now it's =. I would have prefered Forth's !, but that
conflicts with the shell, and = is growing on me. Yes, = is a valid
Bash user-defined function name.
osimplay is pure GNU Bash. It does not need dd, cat or similar for
anything, although I'm starting to use cat for some things in
conjunction with osimplay in the actual build process of a program as
a degenerate linker. I believe Linux does the same thing. It turns out
cat is very difficult to do as a shell function. I may write one in
osimplay and include it. The clip tool included with osimplay is
written in osimplay to trim binaries to 0x7c00 for PC boot floppy
images. It's a single-purpose dd.
osimplay has a simple ELF mechanism for static Linux executables, and
a convenience for calling Linux syscalls, the osimplay Linux word.
osimplay also has a lot more systems programming support than shasm,
since I am now writing predecessors of pmode kernels with it. I keep
one osimplay with the Linux stuff in it and another without, the
latter being for target-system programs like kernels, and arbitrary
data files like fonts. The only difference between the two though is
fewer functions in the target system version.
osimplay has various features in the meta-assembler range, but the
style of what is offered is somewhat unique. I do a reentrant
procedure I call entrance procedures, but unlike, say, Randy Hyde's
HLA, I don't do the usual flow-control abstractions like for-next or
do-while, or even Forth's do-loop. Plain conditional branches (i.e.
GOTO) get a bad rap because they don't sell compilers. Neither do I. I
want to keep osimplay from developing a troublesome semantic seam
between high-level and low-level, and flow-control abstractions are an
area where those start to develop. In Gcc that seam is asm("") (which
the Plan 9 C compiler does not have an equivalent for, by the way),
and in a PD Forth it's CODE words and the runtime interpreter.
osimplay has none of that.
A grep "()" osimplay of the target-system version of osimplay will
produce something like this for the last part of it, which is where
all the osimplay stuff (the most recent layer on shasm) is...
osimplay () { # main(). e.g. osimplay [your source file]
beam () { # Fill a range of an xray with a jump address
cell () { # name/allot a cell-size storage location
copies () { # plural, range-to-range copy, handles overlaps
clump () { # C struct() kinda, data associations namer
leave () { # return from the current reentrant procedure
fill () { # plural, copies A across range @ DI -x86 STOSD
flag () { # assert the zero/sign flags of a register's value
enter () { # how you invoke an osimplay reentrant procedure
maskbyte () { # mask arg down to a byte
maskdual () { # mask arg down to it's lowest-significance 16 bits
match () { # plural, range-range compare, zero flag=match
max () { # max arg1 arg2 leaves greater in arg2
min () { # min arg1 arg2 leaves lesser in arg2
numbering () { # C enum, but not strictly constants and no commas
quad () { # name/allot a 4-byte storage location
quadtohex () { # quad value to ASCII hexadecimal string
range () { # name/allot some count-cell prefixed memory
ring () { # ring-wise increment a strand's index
ringstore () { # ringstore ring reg/lit [arg3 means cell] !A
scale () { Forth */ with a shift instead of a divide
scan () { # plural, compare A to memory range @ DI until
hit/miss
strand () { # name/allot a general array and 8 cells of metadata
sum () { # plural, additive checksum
tag () { # tag ASCII bytes and zeros in a cell
text () { # name/allot some text
xjump () { # indexed jump into an xray execution array
xray () { # name an execution array for beam, yarx and xjump
xsum () { # plural, XOR-ing checksum
yarx () { # finish compembling an xray and it's beams
zero () { # simple convenience to set (a) register(s) to 0
locals () { # help-only word on osimplay familial frame variables
Of those, the ones that I use in boot demos and so on are zero, text,
maskdual, cell, copies and clump. Whatever code needs to be reentrant
so far, I've done with pushes and pulls (pops). My keyboard driver may
use xray and it's helpers. Even writing a text editor, I haven't
gotten into too much use of the reentrant procedure facilities yet. My
rule for parameter-passing by hand is, if you weren't passed it and
aren't returning it, and you need to clobber it, push it first,
clobber it, and pull it. That is, if a register is being used to pass
a value, that register probably doesn't need to be reentrant, i.e. it
has probably been changed in the current pass.
I do like osimplay better than C, even for apps. And I use it.
Something like clumps is a tiny percentage of the functionality of C
structs, for example, but it's the most useful, least problematic
part. That's how osimplay is, and it gets that from Forth. Allow or
facilitate what you can without creating any barriers. That's not far
removed from the philosophy of, say, Perl, but I mean barriers between
the shell prompt and the CPU silicon. And unlike most PD Forths,
assembled osimplay runs on the metal. Forth is a few-level language.
osimplay is a one-level language.
osimplay doesn't have any scoping mechanism yet, and may not get any.
If it does get such things, it will probably use shell function
nesting to implement it. Bash is very good about reentrance and names.
There are local variables afiliated with entrance procedures, but
otherwise variable names in osimplay are all global. In fact, they're
global to your shell. You can assemble something and check $H and
whatnot after the fact, interactively. Things like scoping mechanisms
lose that. Also as a matter of simplicity, the locals in entrance
procedures are pre-named ala sa sb sc...
You can easily do conditional assembly within a file somehow with
shell functions. You complicate matters massively if you do. osimplay
actually uses an extra (third) pass to clean up forward branches, ELF
pointers and so on, and that was a quick hack that just happened to
work. When you start playing games with transient shell state, don't
expect any sympathy. Bell Labs tries to eliminate #if and so on in the
Plan 9 sources, for good reason. If you want to alias a name or
something, you probably want to do it in your working copy of osimplay
itself. "macros" are trivial in osimplay. They are shell functions,
but they bring up the aforementioned transient state issues. osimplay
is in your shell state, which can be messy. If you want to run
osimplay on a major Linux distro, you probably want to set up a very
constrained $PATH for it for similar reasons. If you have something in
$PATH named, say, HL, your sanity will be sorely challenged.
osimplay also got some new state variables recently, which are
actually intended for use as constants. There are names for all the
bit positions in a quad, and there's a $meg and so on. The most
significant bit of a quad is $bit31. 1024 is $k1.
BIG WINS
The big wins in clarity in osimplay versus assemblers like Gas are the
opcode names, dual/quad or cell instead of word/doubleword, selective
non-support of x86 legacy detrius, and the cell concept.
Instruction names in osimplay vary along the terse/verbose axis from
=, + and so on to loadmachinestatusdual, INTeL LMSW. Rarely used
thingies are verbose. = is somewhere on the order of 25% of most code,
and doesn't need to look like MOVW.
I don't support some things I can't see any use for, including the
ASCII conversion instructions and the save instructions for IDTR and
so on. You loaded it, right? Then you know what it is. IF there is a
use for AAA, or the affiliated Auxiliary Carry flag, is it worth the
obscurity? Maybe once in a MULTICS. So use ab and friends to
hand-assemble the little gargoyle.
There are basically two forms of most of the instructions on a 386,
the byte form and the cell form. Duals and quads are a matter of
system context. osimplay doesn't confront you with a global state
variable in every mnemonic. The cell concept will be around awhile,
and it smooths over a lot of the quirks of the x86 quite nicely,
presumably through IA64.
COPING
slowness
osimplay is about a decimal order of magnitude slow than Gcc, and two
orders slower than Gas. Big projects in a sh osimplay will need
defense mechanisms from it's slowness. A 128-glyph VGA font takes
several minutes to compemble on a P166. That's using the
shasm/osimplay binary word and strings of periods and zeros to define
a byte of a letter, rather like X bitmaps as C source. If you do a lot
of that, consider something like variables for the 256 bytes values
that look like thier binary representation. Or whatever. As ridiculous
as osimplay is, the osimplay binary word is an extreme case.
If you're writing a kernel, try to get a monitor or a Forth going on
the target machine as soon as possible, so you can code on the target.
Pre-assemble stuff you're not working on. Pre-assembled fonts and so
on can just be cat'ted onto the end of a binary and pointered to with
clump. Doing something similar with the front end of a binary might
take a bit more finesse.
size issues
Bash has some state-size limit I guess. I'll modify this document when
I hit it. The worse problem is that size costs, if I recall correctly,
do tend to be geometric as time costs. Thus the slowness defenses are
exacerbated. Small is beautiful, eh?
There's a temptation to write osimplay in osimplay, or rework asmacs
to be more like osimplay, so osimplay is faster at assembly time.
That's a lot of work for a small win. It's all about the resulting
binary. The better path is to get a self-extending target system up
ASAP and lose osimplay altogether. osimplay was originally to
portable-ize my 3-stack language, and it still is, but H3sm might as
well become an OS at this point.
PORTING
osimplay uses just the scripting features of Bash, so it's an easy
port to e.g. pdksh. For something like ash osimplay would require expr
also, and I think it uses eval now, which may be a problem. It needs
to be a 32-bit expr, by the way.
Werner Almsberger I believe it was said osimplay looks like the
"bastard offspring of a drunken encounter between INTERCAL and APL."
Thanks so much. He obviously put some effort into that one. What his
left hand is saying while he slings bananas at me with his left foot
is that osimplay is about two orders of magnitude less twisted than
INTeL assembly, and LOOKS like a high-level language. Take it from me,
when it comes to obfuscation, the INTERCAL guys are helpless naifs
compared to INTeL. But, There's More. The APL/INTERCAL look, strange
as it is even to a Forth guy, implies possible portability.
Inter-machine portability is a subjective thing even with something
like C. Gcc would be a nightmare to port to a 2-stack machine (a
silicon Forth engine), for example. In fact, it wouldn't be Gcc any
more. It would structurally be starting over. All the internal AI
stuff Gcc does assumes a single stack, in memory. Within the realm of
register machines, there are two levels. Gcc also, last I looked, and
C itself, don't know much about systems instructions, registers or
concepts like "process".
If you're talking about applications programming on register machines,
making osimplay portable looks doable. That is, osimplay could be as
portable as C. The 386 plurals, i.e. the "string" ops, which x86 does
very differently than other machines, can be hidden behind stock
operation names like fill and so on. The 386 core applications
registers are a subset of most other competing machines. RISCs don't
have the 386 2-register memref, so don't use it. CISCs do have
mem-to-mem addressing for most ops, and x86 doesn't, but that won't
cause conflicts coming FROM x86. One of these days, somebody with a
68040 may do to 386 osimplay what the Plan 9 assembler does, which is
provide a macro for op-mem-mem on 386. Et Cetera.
I heard anecdotally that hand-tweaked Pentium-Pro code runs about 60%
faster on a PPro than plain 386 code. Is it worth it? No. Not as a
stock feature in osimplay it's not. My osimplay will stay straight
386. I personally won't even do floats in osimplay. Chuck Moore says
Forth */ (times-divide, a scaling primitive) makes floating-point
unnecessary. Mostly, yeah. And osimplay scale uses a shift instead of
a divide :o)
BOTTOM LINE
osimplay is a collection of shell functions. Make your osimplay do
want you want. There's no reason not to include the custom osimplay a
particular project is built by right in the project distribution. A
g-zipped osimplay is about 35k.
LAST WORD
YOMV - Your Osimplay May Vary
Rick Hohensee
Beth
> Why drive nails with a hammer instead of a rock?
But if you're hitting those nails on the side rather than trying to
hold them straight and banging straight on the head, then it doesn't
matter which you use, you'll just have a lot of bent nails banged in
at all the wrong angles (possibly sticking out the side of the wood,
splintering it because you banged it in at the wrong angle :)...also,
be sure to bang the nails into the right places...banging a nail into
a wall without first checking for water pipes or mains electricity
could lead to a pretty nasty little catastrophe...
Or, in other words, yes, "the right tool for the right job"
applies...but, further, you must use the right tool in the right way
at the right place and the right time...or, effectively, you might as
well start banging nails with rocks...
Or, returning from the analogy to the subject, "a tool is only as good
as the person who uses it"...you have to hold the hammer by the handle
and steady the nail to make sure it goes in at the right angle (watch
your thumb! We don't want any of those Tom and Jerry big, red
throbbing accidents to happen :) and bang it straight in...you should
check beforehand that you're banging the nail into the right place
(and not accidentally into your main water pipes ;)...also, check the
materials your banging the nail into...perhaps the surface needs
preparation before use...with screws, for instance, you might need to
use rawl-plugs to give the threads something to
grip...blah-blah-blah...
Owning a hammer does not make you good at DIY...many men automatically
seem to assume that it does but it actually doesn't..._skill_ and
_good practice_ are also required...in fact, professionals very often
_DO_ sometimes use the wrong tool on occasion - banging in a nail with
a rock - because even the wrong tool with the right skills and
knowledge are preferrable to the right tool with no knowledge of how
to use it at all...a professional using a rock to bang a nail, just to
save them the bother to go get their hammer, will often produce
acceptable results (though, really, they _should_ be getting the right
tool...ego is no substitute for that :)...whereas, hand a totally
clueless person a box of all the best tools available and then ask
them to try to build something _without the skills_ and _without the
knowledge_...guaranteed, almost, they'll completely fudge the whole
thing up, however "right" their tools were...just because they had no
idea how to actually use those tools or even the correct methods of
doing the task (even if the flat pack instructions are crap, _read
them_ to at least try to work out how it's generally supposed to fit
together and what all those screws and nail supplied are supposed to
be doing ;)...
Thus, in fact, as important as "the right tool for the right job"
is...it's nowhere near as important as "a tool is only as good as the
person who uses it"...ignore the hype used to sell compilers in
adverts, there is simply no substitute for knowledge and skill...
Indeed, many bloated, slow HLL-coded applications do earn the title of
"a botched job built by a cowboy builder" in comparison to the
professional cares not a jot about the tool used so long as the _job
is well done_...the analogy is worryingly far more accurate than it
should be...like building, there's a heck of a lot of "cowboy
builders" in this industry too, doing bad jobs for their
customers...requiring another set of builders to come in and "patch"
over the entirely unsafe job done by the first bunch of builders...
Have you seen the episode of Fawlty Towers where, against Cybill's
instructions, Basil tries to save a few quid hiring a cowboy builder
who uses a wooden lintel on a supporting wall? As with all the
episodes of Fawlty Towers, they can be taken as cautionary tales of
the problems of succumbing to easy solutions...every episode, things
start out perfectly fine but Basil makes the situation worse and worse
and worse by insisting on trying to get out of the problem with an
easy solution rather than a _good, working solution_...does he just
admit fault? Nope, he tries to bluff and lie his way out of
things...does he just resign that if he wants a good job done then
he'll have to hire the better builder? Nope, he accepts any old crap
as long as it saves a few bob...Basil Fawlty is meant to be an example
of entirely how NOT to go about things and the comedy is all about
seeing him try to get out of things with pathetic, unsatisfactory
solutions which are doomed to fail from the start...and, of course,
what truely makes it hilarious is recognising yourself and how you'd
probably also at least give it one go at a cheap, easy solution
too...the surname, of course, is not accidentally...Basil Fawlty is
always trying "faulty" solutions using "faulty" reasoning, which is
why everything always steadily falls apart for him all the time...in
practically every episode, there's a moment where you're thinking "why
doesn't he just _tell_ Cybill what's going on?" and, if he had, the
problems would have immediately disappeared...
I'm sure that Irish fellow Basil hires had a nice, shiney hammer in
his van, too ;)
Beth :)
Aharon Lavie
query. I am sorry to say that I cannot agree with your "mathematical
perspective" which equates the action of ORG to the mathematical
coordinate transformation. You yourself identify a difference between
the two when you write "computers are _dynamic systems_ constrained by
time so, really, the mathematical perspective is NOT the natural
bedfellow." Another difference is that a mathematical coordinate
analysis normally deals with continuous coordinates i.e., uncountable
infinity, in multiple dimensions, while, as Alex McDonald points out,
"Assemblers and ORG operate in one" and this single 'coordinate' is
marked by integers, which are countable even when infinite, let alone
that their number is necessarily finite. But the crucial discrepancy
between ORG and your "mathematical perspective" is - a mathematical
coordinate transformation has its effect on every point in the space
it maps, e.g., the pre-transformation origin is no longer the origin
following a coordinate transformation involving a non-zero
translation. On the other hand, ORG has its effect only on the values
following it and values preceding it retain their original value,
e.g., the origin remains the origin when ORG is coded only in the
midst of the program.
I would prefer another analogy. A timepiece normally counts time
sequentially unit-time by unit-time, e.g., some clocks count time
second by second, in analogy to the location counter counting byte by
byte. Yet there are facilities to turn the clock forwards or
backwards, in analogy to the functionality of ORG. In some countries
the clock is legally advanced one hour ahead before the summer and
turned back one hour before the winter. Events occurring before or
after such change of the time are recorded according to the state of
the clock at the time of the occurrence. This is how ORG functions.
This is not the effect of coordinate transformation. Furthermore,
there is no reference whatsoever to the origin - one does not need to
refer to the Big Bang (if one assumes this to be the origin of time).
In response to your comment "had I seen it from the Plain English
semantics as you do and the inherent 'there can be only one'
restriction that applies to 'origin' when used on humans and so
forth...well, yeah, I'd be just as confused as you and posting the
same questions..." I would like to point out that during my years of
programming I was using ORG to modify the location counter without
giving any thoughts to what I now see as a discrepancy between the
name of this directive and its function. Recently I happened to read
more carefully the manuals for both BAL and MASM and I noticed that
neither use the word "origin" in describing the directive - they both
mention the modification of the location counter. The MASM manual
shows, as an aside, an example for the use of ORG to set the starting
address of a .COM file (BAL provides a different facility for the
mainframe equivalent purpose). I would think that it makes more sense
to interpret ORG as coming from reORGanize rather than from ORiGin.
Funny that you would mention the notation "x = x + 1" which was my
very first confusion when, as a novice, I was exposed to my very first
programming language, a dialect of FORTRAN called ALTAC. This, for
sure, brings up very old memories.
With best wishes
Aharon
-------
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:<XXK1b.759$NR6.2...@newsfep2-gui.server.ntli.net>...
> Aharon Lavie wrote:
> > I started this thread because ORG, coming out of ORiGin, is not "as
> > simple as that." Its function, in both the IBM mainframe BAL and in
> > the X86 MASM, is to modify the location counter at any point in the
> > program, not necessarily at the program origin. This is probably the
> > source of confusion for learner programmers, not realising that ORG
> > has something to do with the origin only at the beginning of the
> > program, but not at its midst.
>
> Depends on your perspective, really; As I mentioned in my other post,
> I look on "ORG" in the more mathematical sense of "the point by which
> things are measured"...what things? Why, instructions in this
> case...the point from which instructions are "measured"? Sure, sounds
> like one possible description of the purpose of the location counter
> because that's the _absolute_ starting point from which subsequent
> instructions are _relatively_ encoded from...
>
> Note, mathematically, you can change your "origin" all the time, no
> problems...hence, the mathematical rather than Plain English semantics
> make the meaning clearer, I believe...in the Plain English meaning,
> it's normally referring to someone's geographical place of birth or
> the source of their family tree or even the beginnings of the human
> race itself ("origin of species")...
>
> Well, all these things are _historical_ and you can't change the
> past...so, if you're not looking at it from a mathematical
> perspective, I can perfectly understand this "Huh? How can it be an
> 'origin' when you can change it all the time?" thinking...historical
> origins are, indeed, quite _singular_ in nature and can't be changed
> at all...history is, by its nature, immutable...it's an inherent
> property of time (as we currently know it): it keeps moving forward
> and you can't go back in time to change things...
>
> On the other hand, mathematics is so abstract it's not even really
> inside the spacetime continuum at all...for dynamic systems where you
> _want_ time to be a factor, you actually have to _artifically_
> introduce it with all that subscript notation stuff (which brings us
> to the infamous mathematical nonsense of "x = x + 1", as an
> example...this does actually make sense in programming because,
> inherently, machines are dynamic systems where _time_ really is an
> inherent factor you can't escape (though, in mathematics, it's not
> there unless you _introduce_ it :)...thus, in mathematical notation,
> it's really "Xt = X(t - 1) + 1" (sorry, can't write subscripts
> properly in ASCII...the "t" and "(t-1)" are subscripts, the rest
> isn't...and "t" represents a variable keeping track of the continuing
> movement of time...though, even with this notation, maths still allows
> you the impossibility of decrementing "t" and abstractually moving
> backwards in time :)...there's no real need to add this to the program
> source, though, because it's an inherent property of the machine and
> you can't escape it...time and tide wait for no-one...
>
> It's all wrapped up in this very, very subtle difference in "ordinary"
> versus "mathematical" semantics...note, though, that the semantics of
> "origin" actually _aren't_ changed at all in both senses...the
> difference is that Plain English "origin" is normally tied to _time_
> and you can't do anything about that...hence, there is only _one_
> singular "origin" for the usual Plain English meaning...
>
> On the other hand, if you do a lot of geometry and think in a
> mathematical mindset, then multiple "origins" are perfectly
> acceptable...it's just a change in the nature of your
> perspective...your starting point for measurements...time isn't an
> inherent property of mathematics so, in a sense, when you re-arrange
> an equation or change your origin, you're just changing your
> perspective on things..."time" doesn't really exist here so, in a
> manner of speaking, no "time" at all passes while you're doing this
> (in a mathematical sense...in a real-world sense, you can't do this
> all instantly so time will pass as you calculate your equations and
> results :)...time is "frozen" while you calculate and, weirdly, from
> the perspective of any "time" in your equations, those equations (were
> they capable) would be amazed by your remarkable ability to seemingly
> be able to comprehend things from infinite perspectives all at the
> same time...if philosophy is your thing, then if there is a God (or
> god or gods or spirit or whatever of the million names humans use)
> that exists outside the constraints of space and time, then it's an
> interesting philosophical thought to consider that they would see
> things in this mathematical sense...it's one of the slip-ups aethists
> would make challenging that any god couldn't possibly be
> omniscient...no, not by the rules _we_ live by, that's entirely
> true...but you're failing to see how much of a massive difference a
> simple change in perspective can be...this would be as much "magic" to
> time-constrained on-lookers, as the infamous "take technology back
> into the past to show people and they'd probably burn you as a 'witch'
> for all your 'evil black magic', refusing to listen to your simple
> explanations of how it actually works and isn't 'magic' in any way,
> shape or form, in fact" ;)...
>
> Thus, as I say, I personally find "ORG" (as in ORiGin :) to be
> perfectly mnemonical and appropriate...but then that's just because,
> coincidentally, I did look at it in the mathematical sense immediately
> so the pieces of the puzzle fell into place...had I seen it from the
> Plain English semantics as you do and the inherent "there can be only
> one" restriction that applies to "origin" when used on humans and so
> forth...well, yeah, I'd be just as confused as you and posting the
> same questions...
>
> The word, I'd say, isn't in any way "wrong" or "inappropriate"...you
> were just looking at it through the "wrong" or "inappropriate"
> lens...put on these mathematical glasses - which have no constraints
> on multiple origins because they are only your "point by which to
> measure things from", which is the basis of your perspective, which
> you're free to change at will - and it shouldn't look fuzzy
> anymore...coming into clear as crystal focus :)...
>
> The choice of word, though, _is_ potentially misleading...the fact
> that you (and probably many others :) have been misled proves
> that...so, perhaps it really should have undergone a bit more thought
> and something "perspective-friendly" chosen (the mathematical sense is
> actually "perspective-neutral", so to speak...but, in this case, being
> "neutral" and "objective" about things is actually the cause of the
> confusion because, usually, no-one is "neutral" or "objective" when
> they use this word in Plain English semantics)...
>
> Anyway, regardless, the history of the evolution of the mnemonic is
> still perfectly interesting, as it will explain _why_ the person who
> invented this was thinking that the mathematical perspective was a
> valid presumption...it's not actually "obvious" because computers are
> _dynamic systems_ constrained by time so, really, the mathematical
> perspective is NOT the natural bedfellow (really, you're thinking in
> the right context, so to speak, and it's interesting to find out why
> the person who thought up "ORG" wasn't...too many geometry lessons at
> school warping their minds? Or some academic insistance that software
> should be looked at from a mathematical perspective - "prerequisite:
> mathematical instruction" not being at all uncommon on a university
> prospectus for a computer course, even though it's really _a logical
> mindset_ that's the true prerequisite - because of typical academic
> prejudices that anything that isn't mathematical is an "art" and
> something to pour scorn over as "fanciful" and "imprecise"...truth is,
> what scientists claim, we can't totally be "objective" and detach
> _personal_ _human_ prejudices from our actions...you try, to be a good
> scientist, but you will always fail in some regard...the trick is to
> fail on some irrelevent point - your _personal_ interest in astronomy
> is your "prejudice" (you _chose_ to be an astronomer, after all, for
> purely subjective personal reasons) - but this doesn't (or shouldn't)
> effect the validity of your observations so that's an "okay prejudice"
> by scientific standards...it effects _what you decide_ to observe but
> _shouldn't_ effect the results of that observation, if you're doing
> things properly and detaching what you want to find from what you
> actually do find...unfortunately, some don't seem entirely capable of
> this at all times ;)...
>
> It's good that you phrased it in this way above, as it's allowed me to
> pinpoint the "perspective problem" here...the point is that a "program
> origin" isn't necessarily a singular entity...yes, that seems
> initially "odd" and "weird" because _human_ "origins" are always
> singular (due to the nature of time...your great grandfather can't
> suddenly change origin - becoming Polish rather than Swedish - so
> these kinds of origins are _always_ "singular"...it is the realm of
> silly sci-fi films to ponder the idea of things like this suddenly
> changing half-way through your life because someone went back in time
> and messed around with the "origins" of things, changing them all
> about...although, truth be told, the past is such a delicate thing and
> prone to choas on a massive scale that any manipulation of the past
> before our lives would almost certainly result in all of us
> immediately ceasing to exist...or, at least, that's the scientist in
> me speaking there...I personally like the notion of "fate" and
> "kismet" and such, even if I have no evidence or grounds (yet...I live
> in Hope :) by which to demonstrate it as "fact" of any kind...are
> "soulmates" fact or emotional illusion? I'll give two completely
> contradictory answers depending on whether I'm wearing my "science
> hat" or not at that particular moment...as I say, you can't really "be
> objective" as people suggest scientists can...the best you can expect
> is that the scientist take pains to distinguish the two and not
> "infect" you with their own personal prejudices...I try to respect
> other people (a subjective thing, again, note) and try to do it
> "properly" for your benefit...as noted, I _will_ fail but at least I
> recognise the problem and am trying to minimise the effects...far too
> many scientists really do think they can put themselves in the
> position of God...I'm a touch arrogant at times, granted, but NOT in
> that direction or context at all...that's not just silly and
> inaccurate and illogical, it's quite blasphemous too...not that
> aethists would care about "blasphemous" in the slightest, I do
> realise, as, to them, there's no-one to be blasphemous too...ooh, all
> this changing perspective and "origin" to attempt to be empathetic
> might, indeed, be mathematically possible but it sure does cause a
> person a big headache thinking in twenty directions all at the same
> time ;)...
>
> Anyway, anyway..."Its function, in both the IBM mainframe BAL and in
> the X86 MASM, is to modify the location counter at any point in the
> program, not necessarily at the program origin"...the presumption that
> your Plain English perspective is misleading you with is that it's
> "_the_ program origin"...when, in fact, it's not necessarily singular
> (you could have entry points all over the place and load in code in
> any old order...worse, into virtual memory, which isn't even holding
> the logical addresses in that particular order physically...the memory
> pages could be all over the RAM with the "origin" as you think of it
> being _after_ the end of the code from the perspective of its source
> code order...generally, though, programming languages, OS
> architectures, exectuable loaders and so forth all respect the "one
> origin" perspective as far as is possible...you might have heard the
> common "only have one entry and one exit from a procedure" programming
> style advice...but that's "convenience" rather than "actuality", so to
> speak...procedures and programs can have multiple entry points and
> exit points and be highly fragmented with no particular physical order
> to them at all...it's generally considered "poor style" because that
> would be a highly confusing mess to unravel (as you demonstrate,
> humans are so trained in the notion of singular "start here, end
> there" because of having to deal with concepts like time inherently in
> practically everything we deal with, that it's "poor style" because it
> violates this and sets up the perfect confusing situation that no-one
> else will be able to unravel very easily :)...
>
> There, in a sense, is no _the_ program origin...after all, the data
> and stack are also part of a program too and can commonly be set quite
> independently of the code...so, is this three "origin"s? Or one origin
> "plus extensions"? Or a case of there not really being an origin at
> all but this is a convenient abstraction for programmers to use
> (which, generally, the simple "dump the load image in memory" loaders
> support and compliment that you usually never have to think from a
> different perspective on this at all :)? And that's the "simple"
> situation...what about program libraries with no "official starting
> point" but entry and exit points all over the place? Worse, they are
> split into multiple files and can be loaded into any order and even
> further confused as to logical order by virtual memory mechanisms...
>
> Nope, don't confuse the notation for what's being notated...the
> location counter has, in fact, no meaning outside of the assembly
> process (there is, indeed, the "program counter" which can often
> mirror the location counter sometimes in certain ways...but, nope,
> it's a _completely different_ thing, really...the program counter
> respects branches, the location counter does not :)...
>
> Anyway, I stress, there's no "right" or "wrong" here...your
> perspective is just _different_ from that of the person - presumably a
> mathematically-trained engineer or something like that - who came up
> with the mnemonic...from your view of things, it's a bad choice of
> word and you'd have picked something different...doesn't really
> matter, they're all arbitrarily chosen, anyway...after all, we're
> saying "origin" but, in fact, the directive is "ORG"...that's not even
> an English word...it's just the "agreement" (well, not really
> agreement...a case of "here it is...like it or lump it"
> you've-got-to-agree-whether-you-want-to-or-not "agreement" ;) that
> it's a nice shorthand that's easy to remember...
>
> If you've used other non-IBM influenced assemblers then this is all a
> moot point usually because they'd be some sort of "* = $5000"
> construction instead or something like it (where "*" is the symbol for
> the location counter, like "$" is on Wintelly-like machines...and it's
> "*" rather than "$" because they've arbitrarily chosen to use a "$"
> prefix for hex numbers rather than "h" suffix :)...
>
> That's one rather minor benefit to C-style symbol-based operators
> rather than mnemonic "words", they are usually (stress on usually, as
> I'm about to present an example where it's _still_ open to debate :)
> outside natural language perspective so there's never any disputes
> over whether something was named properly...
>
> Although, that said, is COBOL "better" because it uses a full stop
> (US: period) to end statements (semi-colons are, of course, the next
> most logical "nautral language" symbol to use because they are close
> in semantics to a full stop...a sort of "full stop that isn't"...and
> the preference for that, initially, I'd presume is totally a lexical
> thing...full-stops are also overloaded as decimal points (and, also,
> commonly referencing structure members...commas would also be under
> consideration but, well, are already used for any "lists" - again,
> borrowed from natural language - so we wouldn't want to flood a
> program's source with commas everywhere ;) too...it's just a whole lot
> easier to parse if you try to avoid multiple uses as much as
> possible...though, practically all languages fail to completely avoid
> double-meanings on operators that you've got to wonder if, at least in
> this one regard, COBOL wasn't totally off its rocker...anyway, too
> late...everyone's got used to the other styles and aren't going to
> change, however "appropriate" it is from a "natural language"
> perspective :)...
>
> > This is probably the
> > source of confusion for learner programmers, not realising that ORG
> > has something to do with the origin only at the beginning of the
> > program, but not at its midst.
>
> Actually, here's the "slip-up", so to speak...the ORG _does_
> potentially have something to do with the origin in its midst too
> (writing bootsector code, in fact, I commonly would always use at
> least _two_ ORG statements - tool permitting - one to locate the start
> of the code at 7C00h, as is a bootsector requirement...but, also, a
> second one to make sure that the 0AA55h "BIOS signature" - used to
> verify its a valid bootsector with BIOSes that can actually be
> bothered to check validity (not all do :) - is at its fixed position
> at the end of the bootsector...the tool normally just zeroes out or
> leaves untouched any intervening bytes...which is okay, as they won't
> be used, other than perhaps as a place to stick a very small initial
> stack to allow CALLs statements and such :)...
>
> Depending on your perspective; This is either a misnamed directive (as
> it's implying only a singular origin when there actually is no logical
> constraint on programs to obey this) or it's correctly named (the
> mathematical "origin" has no problems at all with multiple, changing
> origins :) and just slightly misleading...or, unlike you and me,
> someone out there might think it's both correctly named and not
> ambiguous or misleading at all (presumably the person who invented it
> was of this opinion or they'd probably have thought up a different
> mnemonic instead :)...
>
> It's the dual picture of the woman or the doctor who prescribes
> glasses without diagnosis that I've mentioned a few times
> before...it's not the _object_ that's "wrong" or "inappropriate" in
> this case...it's the "lens" by which you're looking at the
> object...you've got your reading glasses on when you're not reading or
> vice versa...easily done, though, as you'd forget they were even there
> on the end of your nose, if they didn't keep slipping all the time
> which reminds you to push them back up so they don't fall off ;)...
>
> Beth :)
Beth
> Thank you, Beth, thank you very much for your extended response to
my
> query.
It's what I always do, gratitude or not...so thanking me doesn't seem
necessary but it is very polite and appreciated nonetheless :)
Okay, you're overthinking my analogy...applying it well beyond the
bounds of what I was trying to use the analogy to demonstrate...the
only regard I was really referring to was the possibility of
_multiple_ origins, as the mathematical "origin" is not time
constrainted (most often, it's space orientated)...yet, ordinarily, in
natural speech, "origin" tends to refer to a fixed place from a time
past and, thus, there can "be only one" of this type of origin
naturally...that's the sole context where the analogy applies and was
just used to help people get an "outside perspective looking in" on
the issue to see that the problem may not be changing the location
counter multiple times but simply calling it "ORG" ("ORiGin"), which
is carrying Plain English "where I come from in the past" semantics
usually...
In short, perhaps the answer isn't wrong...but it's the way the
question is being asked that's not quite right...as noted, when
written (as found on some non-x86 assemblers I've used, tailored to
use the x86 syntax :) "$ = 400h", it gives it a different
perspective...in this form, why should there only be one assignment?
It makes clear, I believe, that the problem with "ORG" is thinking
"origin" rather than the operation...
That's the reverse angle of mnemonics - that is, devices to aid
memory - that they work well to remind you exactly when
appropriate...but, when not appropriate, they can lead you up the
garden path instead...
> I would prefer another analogy. A timepiece normally counts time
> sequentially unit-time by unit-time, e.g., some clocks count time
> second by second, in analogy to the location counter counting byte
by
> byte. Yet there are facilities to turn the clock forwards or
> backwards, in analogy to the functionality of ORG. In some
countries
> the clock is legally advanced one hour ahead before the summer and
> turned back one hour before the winter.
Daylight savings time; Yes, I'm in one of those countries...started up
because of wanting to maximise daylight hours during the war...but,
well, it worked so well and people liked the extra Sunlight that it
was just allowed to carry on...which leads to the situation that "BST"
(British Standard Time) and "GMT" (Greenwich Mean Time) sometimes run
together but run an hour apart too...
> Events occurring before or
> after such change of the time are recorded according to the state of
> the clock at the time of the occurrence. This is how ORG functions.
> This is not the effect of coordinate transformation. Furthermore,
> there is no reference whatsoever to the origin - one does not need
to
> refer to the Big Bang (if one assumes this to be the origin of
time).
Aye, a more accurate analogy, perhaps...but differentiating between
"real time" and "time measurement" according to Daylight Savings Time?
That's a demanding and potentially confusing analogy...mind you, not
that mine was much better, granted :)
For instance, the "origin" of "real time" would be the Big Bang
(supposing that this theory actually is correct as assumed...unlike
evolution, to which is self-evident and convincing, the 'Big Bang'
cosmological model isn't quite so convincing...not bad, but certainly
not "concrete" yet...one observation - presumed but not confirmed to
be Doppler shift - and a heck of a lot of theorising out of that...and
though some further observations appear to back it up, there's also
been some pretty nasty observations which paint an entirely different
picture...being as objective as possible about this, it's not "fact"
until they can fully explain away these non-corroborating
observations...and, also, of course, the first rule of "proof": other
_independent_ observations that back it up...something else that says
the same thing, which is not based on Doppler shift...if one scientist
claimed "I made people fly!" then no-one would or should take that as
"fact" that people can fly, until another scientist independently
repeats the experiment...it's a fundamental principle of scientific
proof that this must be the case (_even if_ this Decartean principle
does actually make non-repeatable observations outside the realm of
science)...others may want to excuse the "Big Bang" because they like
the sound of it - I confess, it has some very nice psychological
ramifications (how people would like it to be...matching up, at least
to a degree, with the many cultural "creation myths") - but personal
reaction and emotion should be put to one side...sorry, but if you're
a scientist, then there is a duty to simply "bite the bullet" on
_whatever_ the outcome may be, like it or not)...
But the origin of "measured time" is a completely different and
complex affair about various Calendars, adjustments and weird
things...and, well, perhaps I'm wrong and you're right, but I'd avoid
such an analogy because of the potential in confusing one "type" of
time from another...clocks, in a sense, don't "measure time", in fact,
because there is nothing that we know of to sample that is "time"
itself...rather, clocks while away time consistently moving uniformly
through the "time units" and displaying them...
And the difference is more than just pedantic commentary here because
it _does_ make a difference in reality...Einstein notions of
"relativity" and "local time" might have even been imagined earlier by
Newton, if he'd realised the subtle difference...and we don't actually
even need to be travelling at near light speeds to discover
relativity...look up at the night sky...you're seeing the past, not
the present...that supernova may, by now, be long, long over...and
we've always been able to look at the night sky since the dawn of
humankind...it was literally a religious place for the ancients and it
is still ascribed to be referred to as "the Heavens" even today...
> In response to your comment "had I seen it from the Plain English
> semantics as you do and the inherent 'there can be only one'
> restriction that applies to 'origin' when used on humans and so
> forth...well, yeah, I'd be just as confused as you and posting the
> same questions..." I would like to point out that during my years
of
> programming I was using ORG to modify the location counter without
> giving any thoughts to what I now see as a discrepancy between the
> name of this directive and its function.
Granted, a rose by any other name...if they'd called it "QKJZX"
instead - barring the questions of "why call it that?" - then we'd all
have just thought of that as being the "name" and carried on...only
for a few mnemonics do I really sit down and think in terms of "what
it stands for" rather than what it is...things like "move" rather than
"mov" (though, as frequently noted, it's actually a copy...so there's
another badly named mnemonic for you :)..."and", "or" and "add" are
not even mnemonic in the sense that these actually _are_ words (which
can be seen as being the reverse of what I'm talking about by being
"deceived" by the mnemonic...newbies usually have to be _informed_ of
the potential to use "and" and "or" to switch bits on and off because
the English "and" and "or" don't serve any sort of purpose like this,
so it's not immediately apparent from the name alone)...
> Recently I happened to read
> more carefully the manuals for both BAL and MASM and I noticed that
> neither use the word "origin" in describing the directive - they
both
> mention the modification of the location counter. The MASM manual
> shows, as an aside, an example for the use of ORG to set the
starting
> address of a .COM file (BAL provides a different facility for the
> mainframe equivalent purpose). I would think that it makes more
sense
> to interpret ORG as coming from reORGanize rather than from ORiGin.
A possible interpretation; Although, I'm not sure where I heard that
it means "ORiGin" but I must have heard this explicitly...but I'm the
sort of pedantically objective person who never presume such a thing
unless stated explicitly...and would otherwise qualify that it "may"
mean "ORiGin"...and I don't seem to be the only person who must have
heard it stated explicitly as being a mnemonic for "origin" because
everyone else is making the same conclusion...and it's doubtful that
everyone is just all making the same "leap to a conclusion" because,
in fact, "ORG" - just going by the three-letters as read - looks more
like "ORGanisation" or "ORGan / ORGanism" or something...it is, after
all, the three letters used in URLs exactly for "organisation" because
that's most natural...
I'm sure I must have seen it explicitly referred to as "ORiGin"
somewhere or I'd never have thought of it like that...but, well, I
confess I don't recall where...perhaps others can shed light on this
because _everyone_ seems to be assuming "ORiGin" and you're the first
one I've heard casting doubt on it meaning this...not that being a
minority automatically means you're wrong or anything - I should know
that better than most because I often insist being in a minority, _IF_
I feel the majority have simply got it wrong..."truth" and
"popularity" are completely independent, as has been shown many times
in history when everyone agreed on things that turned out to be all
wrong, despite the consensus - but the fact you're the only one I've
heard casting doubt over what "ORG" could stand for does demand
examination, I'm sure you'll appreciate...
> Funny that you would mention the notation "x = x + 1" which was my
> very first confusion when, as a novice, I was exposed to my very
first
> programming language, a dialect of FORTRAN called ALTAC. This, for
> sure, brings up very old memories.
Well, hence my stress on remembering to always examine the _lens_
you're looking through, as well as the object you're looking
at...despite it being what they see, short-sighted people shouldn't
assume that the world really does get "fuzzy" the further it is away
from them...heck, you could easily build up a pretty serious arrogant
egotism from that...that you're somehow centre of the universe, if you
truly believe that the fuzziness you're seeing is actual reality and
not just a problem with the lens with which you look at the
world...like: "everything seems to be fuzzy depending on its distance
from me...therefore, sharpness is centred around me and things fuzz
out toward nothingness as they move away from me...hence, I must be
the centre of reality"...
[ Note, for instance, that exactly this kind of mistake has been made
by astronomical observations, presuming that Earth must be the centre
of the Earth because things seemed to all be encircling it...even if
not uniformly that the geocentric believers started inventing ways to
explain why planets seemed to be going "retrograde" - moving
backwards - in the sky...of course, the observations are perfectly
explained by simply realising that the Earth itself is circling
something else - the Sun - and that, sure, from our perspective, it
all _looks_ to be "encircling" the Earth, even if Earth actually isn't
the centre of the circle...
It's good, though, that humans are capable of learning from their
mistakes...when red shift observations showed more red shift according
to (supposed) distance away from the Earth, they did not make the same
mistake of assuming this meant the Earth is the centre of the universe
with everything rushing away from it...it just _looks_ that way and it
would look that way from _any_ point in the universe where you chose
to make your observations...everything is rushing away from everything
else with the Big Bang cosmological model so it looks like this
_everywhere_...
Modern astronomers have learnt the lesson from a history of jumping to
all the wrong conclusions by misinterpreting what they saw because
they forgot to account for the "lens" from which they were
looking...they know NOT to repeat those sort of mistakes any time soon
and the "lens" always is considered...namely, the geocentric people
couldn't _feel_ the Earth was moving, presumed it to be still and,
thus, if you're still and everything seems to be spinning around you
then, sure, it's a reasonable conclusion from that to presume this
means you're the centre of the solar system (even the universe)...
Though, as I say, the Big Bang may be popularly accepted because it
hit the mainstream media - thanks, most likely to its happy
psychological correspondence with "creation myths" that everyone could
twist it to their already held beliefs of what happened - but, in
fact, it's still a slightly shakey proposition...there's observations
that throw it askew...it hangs, like Damocles' sword, from the single
thread of some red shift observations and trying to explain them...and
it's derived from an awful lot of theorising from those singular
observations...plus, _gravity_ causes red shift too...can we be sure
this is _Doppler_ red shift? Or, even if it is, is _all of it_ Doppler
(multiple red shifts would conspire together and be indistinguishable
from simply looking)? It's not a bad theory and I actually care not
whether it's proved or disproved...but what I want to stress is that
it's actually not really "concrete"...just popular consensus as "most
likely"...which, scientifically, are entirely different worlds...I
await the _proof_ but, until then, however psychologically pleasing or
likely or whatever, the distinction must be maintained...it's a
"theory", NOT a "theorem"... ]
Anyway, regards "x = x + 1", it is the classical
confusion...amazingly, though, I've never seen any texts that explain
the inherent "dynamic" nature of programs that, mathematically, "x"
always implicitly carries a "time" subscript...for those that know
maths, the "x(t+1) = x(t) + 1" (again, ASCII can't do subscripts...so
brackets mark them out :) notation would make it clear...and
explaining it's just a sort of "shorthand" for that (because there's
no need for the time subscripts everywhere, they _universally apply_
because computers require time to do their calculations...mind you,
parallel computers and out-of-order execution - even quantum
computers, one day - may need a revision of that as the "t" subscript
can actually be out-of-order witht the actual instructions
listed...but while software is still written as sequential
instructions and programming languages follow that paradigm - they
don't even really cover concurrency properly, often - then it's still
the best way to explain it :)...
Beth :)