Re: Why is Ada considered "too specialized" for scientific use
Georg Bauhaus
> I was browsing the net for scientific software written in Ada, and came
> across this strange statement:
>
> http://farside.ph.utexas.edu/teaching/329/lectures/node7.html
>
> "Scientific programming languages
> What is the best high-level language to use for scientific programming?
> This, unfortunately, is a highly contentious question. Over the years,
> literally hundreds of high-level languages have been developed. However, few
> have stood the test of time. Many languages (e.g., Algol, Pascal, Haskell)
> can be dismissed as ephemeral computer science fads. Others (e.g., Cobol,
> Lisp, Ada) are too specialized to adapt for scientific use.
>
> ......
>
> The remaining options are FORTRAN 77 and C. I have chosen to use C "
>
> I find this strange, because I think Ada can be the best programming
> language for numerical work. So, I do not know why the author above thinks
> Ada is "too specialized to adapt for scientific use". Is there something in
> Ada which makes it hard to use for scientific programming?
The text, by Professor Fitzpatrick, Physics, 2006, appears to be an
fine example of quite useful justification rhetoric.
(Of the kind well explained by, e.g. Leon Festinger or Irving Goffman.)
It is full of false facts that in general would offer
to an author the comforts of blissful ignorance and a convincing
appearance at the same time. (Who has not been in this situation?
Assuming that a quick proactive defence of your standing is
more tempting than the alternative: is to shut up?)
C99 (note the year) has complex types, says C hasn't. Well, it hadn't,
as some point in the last century.
Inexpensive compilers for Fortran 90 were available that year (2006),
AFAIR, from Intel or the FSF. NAG has academic pricing for its
Fortran compilers, at least now, possibly earlier. There are more.
The info about C++ is rather dated in 2006---templates and
interfaces would be closer to its focus, I'd think. The remark
seems to draw its persuasive power from a brevity that only
repeating hearsay can offer, as someone noted.
During the last few months I had a chance of hearing about Fortran
versus Ada in scientific computing where the subject is concurrent
execution on many processors, with some communication. It turns
out that there is no reason to dismiss either Ada or Fortran,
judging by the results: tasking can be as good as MPI.
There is, however, reason to believe that OpenMP does not scale
well. (From a superficial glance at OpenMP 3.0, I see so many
words sounding familiar in an Ada context (task, barrier, shared,
parallel regions, ...). Are they performing mostly the same experiments
that, I think, were done in the 1970s? I'd speculate that the
parallel constructions aren't novelties in an HPF world, either?)
As Dmitry Kazakov has recently said, when Ada run-time systems
starts addressing the properties of multicore hardware
there is hope that it could really shine: Not just because concurrent
sequential processes are so simple to express using Ada tasks
---and you'd be using only language, not a mix of libraries,
preprocessors, specialized compilers, programming conventions,
etc. But also in case the fine grained complexity of OpenMP 3.0
can be bridled by simple language and a good run-time system.
At little cost.
Keith Thompson
[...]
> C99 (note the year) has complex types, says C hasn't. Well, it
> hadn't, as some point in the last century.
Unfortunately, the C99 standard has not yet been universally adopted.
Very few compilers fully support it. Many support most of it,
but I understand that Microsoft's compiler still supports only C90
(with maybe a handful of C99-specific features).
Which means that as soon as you write "#include <complex.h>", you've
limited the portability of your program.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
none
The only reason I can think of is pure fashion - Ada has not been taken up
as a popular programming language for scientific use, therefore it is not
suitable. But choosing a language based on popularity is not the best
approach - although it does have some validity, providing you recognise
that popular today does not mean popular when you *really* need
maintenance on the software.
Dismissing Algol as ephemeral ignores its influence and continuing usage
as a base of pseudo-codes. Important numerical libraries were first
implemented in ALgol, and later translated to Fortran when Algol's
momentum faltered. But that again confuses usefulness of a language for
scientific programming with popularity. Ada is heavily influenced by
Algol, and I can see nothing in Ada that would prohibbit is wider uptake -
other, again, than fashion. It was a language designed to promote
re-usability, maximise correctness, and include efficiency and
portability, and still has a variety of compilers available, so I can't
see any reason why *not* to use it, if you are proficient in its use.
robin
| On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote:
|
| Dismissing Algol as ephemeral ignores its influence and continuing usage
| as a base of pseudo-codes. Important numerical libraries were first
| implemented in ALgol,
No, they were first implemented in machine code,
and later rewritten in Algol and FORTRAN.
The numerical procedures of the General Interpretive Programme
were written in machine code, from 1955.
Shmuel Metz
at 11:18 AM, "robin" <rob...@dodo.com.au> said:
>No, they
Who is "they"? Note the lack of a universal qualifier. Are you claiming
that all algorithms were developed first in machine code, much less all
algorithms developed in the 1960's and 1970's? For that matter, do you
know of *any* algorithm that was first developed in machine code? I'm sure
that there were some, but I'd expect them to be rare as hen's teeth and
mostly limited to the 1950's and very early 1950's.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Georg Bauhaus
> Georg Bauhaus <rm-host...@maps.futureapps.de> writes:
> [...]
>> C99 (note the year) has complex types, says C hasn't. Well, it
>> hadn't, as some point in the last century.
> [...]
>
> Unfortunately, the C99 standard has not yet been universally adopted.
> Very few compilers fully support it. Many support most of it,
> but I understand that Microsoft's compiler still supports only C90
> (with maybe a handful of C99-specific features).
>
> Which means that as soon as you write "#include <complex.h>", you've
> limited the portability of your program.
OHOH, scientific programs would require best use of your
computer's resources, wouldn't they? So
(1) why run scientific programs on an OS (still largely written in C
AFAIK ...) that by default makes a herd of programs and services keep
your computer really busy without your program running, and
(2) why not use a better C compiler (if it has to be C) even on
MS Windows, such as the ones listed below---if it has to be C?
(I should add that the MS OS is purchased at a higher price
than most alternatives, too; price was a listed as an issue.)
But indeed, even though there is C in Windows NT,
"Thanks for taking the time to send us your suggestion. Currently, there are
no plans to implement C99 support in VS2010. Once we complete this product
cycle, we will be reviewing all customer suggestions, including this one, for
our future planning.
"Thanks,
Mark Roberts
Visual C++ Team"
http://connect.microsoft.com/VisualStudio/feedback/details/485416/support-c99
So for scientific computing, MS C will be a less attractive choice
than GNU C or Intel C, or Comeaucomputing's C on top of MS C adding
C99 to MS C, or ...
Or less attractive than compilers for one of the other
languages such as Ada or Fortran or ... that support both fairly recent
standards and computing with complex numbers.
robin
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
news:4bbb2246$8$fuzhry+tra$mr2...@news.patriot.net...
| In <4bba8bf1$0$56418$c30e...@exi-reader.telstra.net>, on 04/06/2010
| at 11:18 AM, "robin" <rob...@dodo.com.au> said:
|
| >No, they
|
| Who is "they"? Note the lack of a universal qualifier.
Because you cut the sentence and the one before it,
you lost the significance.
Restoring it, we have:
"| Dismissing Algol as ephemeral ignores its influence and continuing usage
"| as a base of pseudo-codes. Important numerical libraries were first
"| implemented in ALgol,
"No, they were first implemented in machine code,
"and later rewritten in Algol and FORTRAN."
you can see that it is patently obvious that "they" refers
to "Important Numerical libraries".
| Are you claiming
| that all algorithms were developed first in machine code,
You will also realize that it's referring to important ones,
and that it's disputing the claim that such libraries were first implemented in Algol.
| much less all
| algorithms developed in the 1960's and 1970's? For that matter, do you
| know of *any* algorithm that was first developed in machine code? I'm sure
| that there were some, but I'd expect them to be rare as hen's teeth and
| mostly limited to the 1950's and very early 1950's.
Restoring the immediately following sentence that you also cut out,
we see that I said:
"The numerical procedures of the General Interpretive Programme
"were written in machine code, from 1955."
which means that the procedures of "General Interpretive Programme"
were written in machine code, from 1955 --
which predates Algol by several years, does it not?
As for your supercilious question, do I <<know of *any* algorithm that was first
developed in machine code?>> --
Had you actually read my post, you would have seen that I gave
reference to a important numerical library.
Come to think of any numerical algorithm developed before Algol,
you may have heard of J. H. Wilkinson's work on numerical algorithms,
for which he wrote machine code from 1947. In his other early work,
he wrote programs (machine code) to solve simultaneous equations
back in about 1951.
as for any algorhtin
Warren
news:4bbb3f22$0$7660$9b4e...@newsspool1.arcor-online.net:
..
> (2) why not use a better C compiler (if it has to be C) even on
> MS Windows, such as the ones listed below---if it has to be C?
>
> (I should add that the MS OS is purchased at a higher price
> than most alternatives, too; price was a listed as an issue.)
They didn't even take advantage of C's own type system.
Everything flows through a WORD or DWORD. The win api
is so very lame because of this. The C++ layer is
better, but..
> Or less attractive than compilers for one of the other
> languages such as Ada or Fortran or ... that support both fairly
> recent standards and computing with complex numbers.
Obviously Fortran persists because of existing code base and
those that only "know" that. But egads, the current rendition
of Fortran seem to have so many "bags on the side" and is
downright "butt ugly". Why anyone would want to continue
to wallow in that swill, is beyond me. Ada as a language OTOH,
is so nice and clean by comparison.
Warren
Sebastian Hanigk
> Obviously Fortran persists because of existing code base and
> those that only "know" that. But egads, the current rendition
> of Fortran seem to have so many "bags on the side" and is
> downright "butt ugly". Why anyone would want to continue
> to wallow in that swill, is beyond me. Ada as a language OTOH,
> is so nice and clean by comparison.
I won't even start with your puny attempts at a language crusade,
suffice to say that all the niceness and cleanness is quite unusable if
you don't have a compiler. And on most supercomputers where serious
number crunching is performed, you do not have an Ada compiler and even
building gnat would be a very major pain (bootstrapping ...).
Regards,
Sebastian
J. Clarke
What is the objection to using the C++ complex library?
Warren
> Warren <ve3...@gmail.com> writes:
>
>> Obviously Fortran persists because of existing code base and
>> those that only "know" that. But egads, the current rendition
>> of Fortran seem to have so many "bags on the side" and is
>> downright "butt ugly". Why anyone would want to continue
>> to wallow in that swill, is beyond me. Ada as a language OTOH,
>> is so nice and clean by comparison.
>
> I won't even start with your puny attempts at a language crusade,
....
> Sebastian
Wooo-oooo, aren't we snubby today.
Warren
Georg Bauhaus
(Or, in other circumstances, objections to using a library such
as Leda maybe.)
I'll speculate about two major reasons for not hoping for the C++
complex library to replace Fortran function libraries any time soon.
At least in some domains...
One reason would be successful tradition: a researcher has successfully
written a scientific program using knowledge available with Fortran 77;
moving to Fortran 90 has improved the solution. Why switch to
non-Fortran? The post-hoc fallacy aside, if non-Fortran is C++, to use
C++ effectively it takes learning a language integrating very many parts
in far reaching and novel ways (from the researcher's perspective).
Most parts need to be well understood in order to bridle the compiler.
To him or her, what is the indisputable advantage of C++ in relation to,
say, a modern subset of recent Fortran? Maybe the support of physical
unit checks at compile time is an example. But the mechanisms behind
template specialization based C++ computation are not that easy to
grasp, are they? At least hardly easier than just moving to Fortran 95
or later and manually checking units by paying attention.
Remembering professor Fitzpatrick's published remark that started this
thread, a researcher's job is probably focused on computing scientific
results rather than optimizing language use. So Fortran 90 it is, or
C---until a new generation of researchers and research problems
gives rise to a new tradition of similarly forced attire using another
language. Technical arguments involving language properties beyond
immediate necessity are subordinate, as ever. After all,
we continue to pay them for this style scientific software! ;-)
[end of speculation]
J. Clarke
Look, you were whining about "MS C" not implementing a complex data type.
Well Visual C++ 2008, which is the only "MS C" in current production,
most assuredly DOES implement a standards-compliant complex data type,
so I don't really understand the point of your complaint.
Georg Bauhaus
> Look, you were whining about "MS C" not implementing a complex data type.
Did I? I didn't. I remember saying that even in 2006 (from which
the note in question dates) there were well enough compilers
supporting C99 on Windows NT.
If VC2010 doesn't support C99, as reported, then still this perceived
lack would not have been a reason to dismiss C just for lack of a
complex data type. And in fact, VS2005, which was available in 2006,
does not have <complex.h> for C. VC++ does support <complex>,
but enough harm has been done in assuming that writing C using
a C++ compiler is a good idea.
> Well Visual C++ 2008, which is the only "MS C" in current production,
> most assuredly DOES implement a standards-compliant complex data type,
> so I don't really understand the point of your complaint.
My complaint, or observation, is that more than one researcher
talking about programming languages tends to act as a show man
when he or she does not really (need to) know what he or she is
talking about. This creates gossip, perpetuates hearsay, and,
by imitation, drives the choice of programming language for
research. Obviously then, decisions to use this or that language
will not be as informed as could be. Chances are that program
quality suffers. I hope this observation can be shown to be wrong.
MRE
Depends on your cost-model. If your man-hours for writing the code
don't count,
go on with C or Fortran. If they are a factor, maybe it's worth to
spend a couple of thousand
for getting support from a compiler vendor to port GNAT.
Thanks btw. for showing quite clearly, that it's not only the "Ada-
Guys" who are
rude.
Marc
J. Clarke
> On 4/7/10 6:25 AM, J. Clarke wrote:
>
>> Look, you were whining about "MS C" not implementing a complex data type.
>
> Did I? I didn't. I remember saying that even in 2006 (from which
> the note in question dates) there were well enough compilers
> supporting C99 on Windows NT.
>
> If VC2010 doesn't support C99, as reported, then still this perceived
> lack would not have been a reason to dismiss C just for lack of a
> complex data type. And in fact, VS2005, which was available in 2006,
> does not have <complex.h> for C.
So what?
> VC++ does support <complex>,
> but enough harm has been done in assuming that writing C using
> a C++ compiler is a good idea.
What "harm" is this? And in point of fact, VS2005 has no C compiler
except the C++ compiler that you say should not be used for writing C.
What you are calling a "C compiler" is in fact a command line switch
applied to the C++ compiler.
>> Well Visual C++ 2008, which is the only "MS C" in current production,
>> most assuredly DOES implement a standards-compliant complex data type,
>> so I don't really understand the point of your complaint.
>
> My complaint, or observation, is that more than one researcher
> talking about programming languages tends to act as a show man
> when he or she does not really (need to) know what he or she is
> talking about. This creates gossip, perpetuates hearsay, and,
> by imitation, drives the choice of programming language for
> research. Obviously then, decisions to use this or that language
> will not be as informed as could be. Chances are that program
> quality suffers. I hope this observation can be shown to be wrong.
My complaint is that you seem to be complaining to be complaining. If
you're using a C++ compiler then write C++, don't whine because its C
support is half-assed.
Georg Bauhaus
> On 4/7/2010 2:43 AM, Georg Bauhaus wrote:
>> And in fact, VS2005, which was available in 2006,
>> does not have <complex.h> for C.
>
> So what?
If there is no C99 but MS and C and scientific programming is
required, this means you can only write C++ programs using MS
tools if you want objects of standard complex types. (Or choose
Ada or Fortran or ...) But C++ was not mentioned as an option.
>> VC++ does support <complex>,
>> but enough harm has been done in assuming that writing C using
>> a C++ compiler is a good idea.
>
> What "harm" is this? And in point of fact, VS2005 has no C compiler
> except the C++ compiler that you say should not be used for writing C.
> What you are calling a "C compiler" is in fact a command line switch
> applied to the C++ compiler.
C++ overlaps C to a large extent. But the compilers
must arrange for the parts of the languages outside the
respective other language. However little one might think these
differences are, ignoring them can lead to error and to portability
trouble.
MS C and MC C++ are therefore, strictly speaking, impossibly the
same compilers. But: referring to more than a command line switch,
Microsoft compilers for many languages use some of the common MS
translation technology. That does not make the input languages
the same. Just like an Intel C++ compiler and an Intel Fortran
compiler share some circuitry, AFAIK. This still does not make
C++ or Fortran interchangeable. GCC can be made to translate
a number of languages. That does not make the languages basically
the same, and not even does it make the dialects of C the same:
GCC with -std=c99 and with -std=c89 accept a different set of programs.
Even when the effective compiler "program" is changed "merely" by a
switch. You might call this nitpicking, but observing the little
differences contribute to program quality IMO. If the latter
does not count, then why bother to consider language properties
in the first place?
> My complaint is that you seem to be complaining to be complaining. If
> you're using a C++ compiler then write C++, don't whine because its C
> support is half-assed.
Fitzpatrick wanted to write C, not C++, and he wanted standard
complex types. So why should he be using a C++ compiler with
half-assed support for C99 without complex? (He, not me.)
Writing C using a C++ compiler creates, in addition to other things,
the hurdle of having to understand C++ in order to make sense of
error messages. (But OTOH, the C++ error messages of some compilers
*can* be a lot better than C's in some situations.) The unfortunate
notion behind "C/C++" incidentally creates a business opportunity for
those who wish to be consultants, recongnizing the "pragmatically"
blurred approach to language use. Note that this is not the same as
integrating modules written in C and other parts of a program written
in C++.
But this is moving off topic.
Keith Thompson
[...]
> Well Visual C++ 2008, which is the only "MS C" in current production,
> most assuredly DOES implement a standards-compliant complex data type,
> so I don't really understand the point of your complaint.
This is off-topic, but ...
I'm sure the C++ compiler implements C++'s complex type. Does it
support C99 complex types when invoked as a C compiler? They're
defined quite differently; they have to be, since standard C doesn't
have operator overloading.
Here's a test case, a complete translation unit that should compile
without error with a conforming C99 compiler:
double _Complex new;
C and C++ are two different languages.
Simon Wright
> As for your supercilious question, do I <<know of *any* algorithm that
> was first developed in machine code?>> --
Wasn't Ada Augusta's first program an algorithm to compute Fibonacci
numbers? That would certainly have been in machine code.
And Alan Turing thought in machine code ...
J. Clarke
> "J. Clarke"<jclarke...@cox.net> writes:
> [...]
>> Well Visual C++ 2008, which is the only "MS C" in current production,
>> most assuredly DOES implement a standards-compliant complex data type,
>> so I don't really understand the point of your complaint.
>
> This is off-topic, but ...
>
> I'm sure the C++ compiler implements C++'s complex type. Does it
> support C99 complex types when invoked as a C compiler? They're
> defined quite differently; they have to be, since standard C doesn't
> have operator overloading.
>
> Here's a test case, a complete translation unit that should compile
> without error with a conforming C99 compiler:
>
> double _Complex new;
>
> C and C++ are two different languages.
Precisely. And Microsoft is not touting any of their current projects
as a C compiler so why should they support C99?
Look, you have a choice, you can use C or you can use Microsoft
compilers, but if you're expecting state of the art C from Microsoft
you've come to the wrong shop.
I just don't understand what's so great about C that one MUST use it in
preference to C++.
robin
"Simon Wright" <si...@pushface.org> wrote in message news:m2tyrnj...@pushface.org...
He did, because he wrote programs (including subroutines)
back in 1945 when he designed the Automatic Computing Engine.
Ken Thomas
a bad start because of the high cost of entry. Compilers were £1000+
for one licence (remember dongles).
However, the recent Ada standards (2005) are very attractive. It is
possible to interface software from other languages (MPI, Metis,
UMFPACK) and the tool from gnat g++ -c -fdump-ada-spec ... is quite
exciting. The containers are also useful. I have used an instaniation
of Ada.Containers.Ordered_Maps to contain sparse matrices.
Some of the applications are finite element software for Maxwell's
equations.
Shmuel Metz
at 01:30 AM, "robin" <rob...@dodo.com.au> said:
>Because you cut the sentence and the one before it,
>you lost the significance.
No. You still don't get the significance of what you replied to.
>Restoring it, we have:
Bupkis.
>"| Dismissing Algol as ephemeral ignores its influence and continuing
>usage "| as a base of pseudo-codes. Important numerical libraries were
>first "| implemented in ALgol,
Read it carefully this time and note what words it doesn't contain.
>"No, they were first implemented in machine code,
>"and later rewritten in Algol and FORTRAN."
>you can see that it is patently obvious that "they" refers
>to "Important Numerical libraries".
Then Does "No" also refer to them? Because that "No" is dead wrong.
>You will also realize that it's referring to important ones,
Who decides what's important? Do you believe that no important algorithms
were written in the late 1950's, the 1960's and the 1970's?
>and that it's disputing the claim that such libraries were first
>implemented in Algol.
Yes, because you're confusing existential quantifiers with universal
quantifiers.
>Restoring the immediately following sentence that you also cut out,
Because it was irrelevant.
>we see that I said:
> "The numerical procedures of the General Interpretive Programme
> "were written in machine code, from 1955."
Which has nothing to do with the point in dispute.
>Had you actually read my post,
ROTF,LMAO. Too bad you didn't read your own post before replying to mine.
>you would have seen that I gave reference to a important numerical
>library.
Strangely enough, I also noticed that it was a library, not an algorithm.
I also noticed that the algorithms in it were not the only algorithms ever
to be developed.
>Come to think of any numerical algorithm developed before Algol, you may
>have heard of J. H. Wilkinson's work on numerical algorithms, for which
>he wrote machine code from 1947.
Algorithms that were developed on dead trees. Translations of existing
algorithms are not what is in dispute.
Shmuel Metz
at 08:27 PM, Simon Wright <si...@pushface.org> said:
>Wasn't Ada Augusta's first program an algorithm to compute Fibonacci
>numbers? That would certainly have been in machine code.
But was it a new algorithm, or merely a transcription of an algorithm that
she already knew? And, more important, do you know for a fact that *Robin*
knew about it? Note carefully what I asked and what I didn't ask.
Warren
858d88...@s9g2000yqa.googlegroups.com:
> However, the recent Ada standards (2005) are very attractive. It is
> possible to interface software from other languages (MPI, Metis,
> UMFPACK) and the tool from gnat g++ -c -fdump-ada-spec ... is quite
> exciting. The containers are also useful. I have used an instaniation
> of Ada.Containers.Ordered_Maps to contain sparse matrices.
Speaking of 2005, I wouldn't mind acquiring a book on
the essential elements of the 2005 features in Ada,
without trudging through dry RM type prose. However,
it seems that these new books are quite pricey,
even used. Normally I can find a suitable deal on
abebooks.com, but have come up empty so far.
There must be a digestable summary on the net somewhere.
Resources?
Warren
Georg Bauhaus
> Speaking of 2005, I wouldn't mind acquiring a book on
> the essential elements of the 2005 features in Ada,
> [...]
>
> There must be a digestable summary on the net somewhere.
> Resources?
The Ada Rationale would be one such resource.
http://www.adaic.org/standards/rationale05.html
Charmed Snark
@newsspool3.arcor-online.net:
Thanks. Someone else emailed me about that as well,
and so I went back and took a more serious look at
it (my lazy- my bad). There is indeed a good summary
of the change there.
Some very happy changes in there!
Warren
Colin Paul Gloster
|---------------------------------------------------------------------|
|"[..] |
| |
|As Dmitry Kazakov has recently said, when Ada run-time systems |
|starts addressing the properties of multicore hardware |
|there is hope that it could really shine: Not just because concurrent|
|sequential processes are so simple to express using Ada tasks |
|---and you'd be using only language, not a mix of libraries, |
|preprocessors, specialized compilers, programming conventions, |
|etc. But also in case the fine grained complexity of OpenMP 3.0 |
|can be bridled by simple language and a good run-time system. |
|At little cost." |
|---------------------------------------------------------------------|
I met someone today who described himself as "an ordinary FORTRAN
programmer" who advocated C for the practical reason that libraries
are designed for C. He claimed that small tasks are good for multicore
and large tasks are good for GPUs.
robin
| In <m2tyrnj...@pushface.org>, on 04/07/2010
| at 08:27 PM, Simon Wright <si...@pushface.org> said:
|
| >Wasn't Ada Augusta's first program an algorithm to compute Fibonacci
| >numbers? That would certainly have been in machine code.
|
| But was it a new algorithm, or merely a transcription of an algorithm that
| she already knew?
That's irrelevant.
robin
| Who decides what's important? Do you believe that no important algorithms
| were written in the late 1950's, the 1960's and the 1970's?
I already pointed out that important algorithms were first written
in machine code in the 1950s ; In fact, a whole suite of them --
all before they were written in Algol.
J. Clarke
And the Euclidean Algorithm was written in Greek several thousand years
before there was such a thing as "machine code".
I think you're conflating algorithms and programs. An algorithm is a
procedure for doing something. A program implements that algorithm on a
particular set of hardware. Most development of algorithms is done with
pencil and paper, not a programming language.
Dmitry A. Kazakov
> I think you're conflating algorithms and programs. An algorithm is a
> procedure for doing something. A program implements that algorithm on a
> particular set of hardware. Most development of algorithms is done with
> pencil and paper, not a programming language.
Algorithm is a program running on the hardware of human brain, "programmed"
in some more or less formal system. Some algorithms can be translated into
other systems (computer programming languages) for other hardware
(computers), which is a part of what we call programming.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Florian Weimer
> Unfortunately, the C99 standard has not yet been universally adopted.
> Very few compilers fully support it. Many support most of it,
> but I understand that Microsoft's compiler still supports only C90
> (with maybe a handful of C99-specific features).
SPEC2006 contains a benchmark which needs C99 complex values (or some
variant of that), so you better support that, or you can't get a
score.
J. Clarke
If you consider what humans do to be "running a program".
robin
| In <4bc5a414$0$78577$c30e...@exi-reader.telstra.net>, on 04/14/2010
| at 07:32 PM, "robin" <rob...@dodo.com.au> said:
|
| >I already pointed out that important algorithms were first written in
| >machine code in the 1950s
|
On the contrary, I substantiated it twice.
Nomen Nescio
>
> On the contrary, I substantiated it twice.
Not only did you not substantiate it, you didn't even instantiate it!
Now the thread is back on-topic!
Shmuel Metz
at 07:32 PM, "robin" <rob...@dodo.com.au> said:
>I already pointed out that important algorithms were first written in
>machine code in the 1950s
I know what you claimed; you have neither substantiated it nor shown its
relevance to the points in dispute. Which part of ":all" don't you
understand? Why do you believe that "all" is present in sentences that
clearly lack it?
Shmuel Metz
at 07:27 PM, "robin" <rob...@dodo.com.au> said:
>That's irrelevant.
The dispute is about the development of algorithms, not about their
transcription. The question of whether Ada actually developed the
Fibonacci algorithm is highly relevant to that question.
Shmuel Metz
at 01:10 AM, "robin" <rob...@dodo.com.au> said:
>On the contrary, I substantiated it twice.
No, you twice made totally irrelevant claims. Nothing that you have
written has any bearing on whether algorithms were developed in Algol 60,
and you haven't even substantiated the claim that important algorithms
were *DEVELOPED* (NOT TRANSLATED INTO) in machine code.
sjw
<spamt...@library.lspace.org.invalid> wrote:
> In <m2tyrnjc5f....@pushface.org>, on 04/07/2010
> at 08:27 PM, Simon Wright <si...@pushface.org> said:
>
> >Wasn't Ada Augusta's first program an algorithm to compute Fibonacci
> >numbers? That would certainly have been in machine code.
>
> But was it a new algorithm, or merely a transcription of an algorithm that
> she already knew? And, more important, do you know for a fact that *Robin*
> knew about it? Note carefully what I asked and what I didn't ask.
Sorry, can't be bothered. Especially since this thread was all about
algorithms being *implemented* not *developed*.
robin
| In <4bc72c60$0$78575$c30e...@exi-reader.telstra.net>, on 04/16/2010
| at 01:10 AM, "robin" <rob...@dodo.com.au> said:
|
| >On the contrary, I substantiated it twice.
|
| No, you twice made totally irrelevant claims. Nothing that you have
| written has any bearing on whether algorithms were developed in Algol 60,
| and you haven't even substantiated the claim that important algorithms
| were *DEVELOPED*
Had you actually read what I wrote in my first post in this thread,
you would have comprehended that I said "first IMPLEMENTED in machine code"
(emphasis added).
And I twice substantiated my claim.
Shmuel Metz
at 06:43 PM, "robin" <rob...@dodo.com.au> said:
>Had you actually read what I wrote in my first post in this thread,
I did; it was both irrelevant and unsubstantiated.
>you would have comprehended that I said "first IMPLEMENTED in machine
>code"
See above.
>And I twice substantiated my claim.
No; you neither identified the algorithms to which you were referring nor
demonstrated that they had not previously been implemented on, e.g., dead
trees, mechanical calculators.
Shmuel Metz
04/16/2010
at 04:04 AM, sjw <simon.j...@mac.com> said:
>Sorry, can't be bothered. Especially since this thread was all about
>algorithms being *implemented* not *developed*.
How do you develop an algorithm without implementing it, if only and a
pencil and a dead tree? Would you claim that, e.g., Euclid's Algorithm,
was not developed until the advent of computers?
robin
| In <4bc97500$0$78577$c30e...@exi-reader.telstra.net>, on 04/17/2010
| at 06:43 PM, "robin" <rob...@dodo.com.au> said:
|
| >Had you actually read what I wrote in my first post in this thread,
|
| I did; it was both irrelevant and unsubstantiated.
You're wrong on both counts.
| >you would have comprehended that I said "first IMPLEMENTED in machine
| >code"
|
| See above.
|
| >And I twice substantiated my claim.
|
| No; you neither identified the algorithms to which you were referring
What don't you understand about "General Interpretive Programme".
That's the algorithm. It's the one I indentified. Four times now.
nor
| demonstrated that they had not previously been implemented on, e.g., dead
| trees, mechanical calculators.
That's irrelevant.
But if you want an example of that, try computer-produced music.
Gary L. Scott
> In<4bcfaa84$0$895$c30e...@exi-reader.telstra.net>, on 04/22/2010> 1. You have not addressed the question of whether Algol was used
> to develop algorithms. Even had you *shown* that other languages
> had been used earlier or more often, that would have not addrssed
> the issue in dispute.
>
> 2. You cited a book describing multiple algorithms; you refused to
> identify specific algorithms about which you were making claims.
>
> 3. You profused to show that the unspecified algorithms about which
> you made claims had not already been in use.
>
Children, children!
robin
| In <4bcfaa84$0$895$c30e...@exi-reader.telstra.net>, on 04/22/2010
| at 11:39 AM, "robin" <rob...@dodo.com.au> said:
|
|
| to develop algorithms. Even had you *shown* that other languages
| had been used earlier or more often, that would have not addrssed
| the issue in dispute.
That is irrelevant. It is not what I claimed.
| 2. You cited a book describing multiple algorithms; you refused to
| identify specific algorithms about which you were making claims.
What don't you understand about the word "Programme"?
It is a computer program.
"General Interpretive Programme" is the name of the program,
and also, incidentally, the name of a book.
Shmuel Metz
at 11:39 AM, "robin" <rob...@dodo.com.au> said:
>You're wrong on both counts.
1. You have not addressed the question of whether Algol was used
to develop algorithms. Even had you *shown* that other languages
had been used earlier or more often, that would have not addrssed
the issue in dispute.
2. You cited a book describing multiple algorithms; you refused to
identify specific algorithms about which you were making claims.
3. You profused to show that the unspecified algorithms about which
you made claims had not already been in use.
--
robin
| In <4bc5a413$0$78577$c30e...@exi-reader.telstra.net>, on 04/14/2010
| at 07:27 PM, "robin" <rob...@dodo.com.au> said:
|
| >That's irrelevant.
|
| The dispute is about the development of algorithms,
No it isn't.
But if you want original development, try
1. Compilers, typically first written in 1950s in machine code.
2. Nuclear codes.
3. Computer-generated music
4. Random number generation.
| not about their
| transcription. The question of whether Ada actually developed the
| Fibonacci algorithm is highly relevant to that question.
That's complerely irrelevant.
J. Clarke
> "Shmuel (Seymour J.) Metz"<spam...@library.lspace.org.invalid> wrote in message
> news:4bc6e42f$2$fuzhry+tra$mr2...@news.patriot.net...
> | In<4bc5a413$0$78577$c30e...@exi-reader.telstra.net>, on 04/14/2010
> | at 07:27 PM, "robin"<rob...@dodo.com.au> said:
> |
> |>That's irrelevant.
> |
> | The dispute is about the development of algorithms,
>
> No it isn't.
> But if you want original development, try
> 1. Compilers, typically first written in 1950s in machine code.
I think that's a very solid case--there was no need for such a thing
before there was machine code so there was no incentive for anybody to
even look for the necessary algorithms, although some of the pieces may
have had prior development, and you can't use a high level language
until you have a working compiler for it (although I understand that in
some cases the "compiler" was a grad student).
> 2. Nuclear codes.
Were the algorithms they used developed to be used on computers or were
they computer implementations of the hand and card-machine algorithms
that were used during the development of the bomb? Los Alamos didn't
have a mechanical computer you know--"computer" at Los Alamos was a job
title--but they did have a room full of punch-card machines and a group
of teenagers doing amazing things with them.
> 3. Computer-generated music
Don't know anything about that.
> 4. Random number generation.
How were random numbers generated before computers? Did they not have
viable algorithms for the purpose?
Peter Flass
>
>> 4. Random number generation.
>
> How were random numbers generated before computers? Did they not have
> viable algorithms for the purpose?
>>
I think the "Chem Rubber Bible" has a table of random numbers you can
use; just pick a spot to start. OTOH, that begs the question of how
they were generated in the first place. I have visions of a roomful of
people flipping coins.
Sjouke Burry
Just take any bad quality resistor, zenerdiode, or a number
of other electronic components, amplify the noise, and use it
with a bit of hardware to produce an endless stream of random numbers.
No computers needed.
Gary L. Scott
Dick Hendrickson
of the finiteness of the charge on an electron, not the electrons quality.
Dick Hendrickson
glen herrmannsfeldt
(snip)
> Just take any bad quality resistor, zenerdiode, or a number
> of other electronic components, amplify the noise, and use it
> with a bit of hardware to produce an endless stream of random numbers.
> No computers needed.
Well, you need at least some digital logic to convert it
into a number. There is a paper by intel on their design for
a random number generator based on such noise sources.
-- glen
Richard Maine
> Excellent time to trim nonessential newsgroups
That would be all of them in this case. :-)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Shmuel Metz
at 05:29 PM, "robin" <rob...@dodo.com.au> said:
>No it isn't.
When you deny that important numerical algorithms were developed in a
particular language, how is the dispute not about the development of
algorithms?
>But if you want original development, try
>But if you want original development, try
You still are doging the point in dispute. Nobody claimed that everything
was developed in Algol, that most algorithms were developed in Algol or
that Algol was the first language to be used to develop algorithms. You're
attempts to change the subject remind me more and more of your friend
David Frank.
robin
| "none" <no...@none.net> wrote in message news:pan.2010.04.05...@none.net...
|| On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote:
||
|| Dismissing Algol as ephemeral ignores its influence and continuing usage
|| as a base of pseudo-codes. Important numerical libraries were first
|| implemented in ALgol,
|
| No, they were first implemented in machine code,
| and later rewritten in Algol and FORTRAN.
| The numerical procedures of the General Interpretive Programme
| were written in machine code, from 1955.
|
|| and later translated to Fortran when Algol's
|| momentum faltered.
For the record, algorithms in the following areas were
first written in machine code, from the mid-1940s,
and run from the early 1950s.
Differential equations
solving linear equations
latent roots
matrix multiplication
calculate determinants
matrix transpose
matrix inversion
linear porogramming
multple linear regression
statistical tabulations.
input and output
floating-point arithmetic (software)
Most were part of the General Interpretive Programme,
developed at National Physical Laboratory by 1955.
In particular, 129 simultaneous equations solved on Pilot ACE in 1952.
Simultaneous equations and second-order differential equations were solved,
and are documented in proceedings of 1953 NPL symposium.
Aircraft flutter design calculations were done in 1952 with the introduction of jet
aeroplanes -- made compulsory in 1954 following investigations of
crashes of the Comet (the investigation itself required extensive computer calculations).
Crystallography calculations from 1954.
Just to mention a few ...
Warren
Sampling speed is another critical factor. If sampling
exceeds the bit flip rate, then it becomes less "random" ;-)
Warren
robin
| On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote:
| Dismissing Algol as ephemeral ignores its influence and continuing usage
| as a base of pseudo-codes. Important numerical libraries were first
| implemented in ALgol, and later translated to Fortran when Algol's
| momentum faltered.
Here's another example that I came across today:
Don Shell published his algorithm in machine code.
(A High-Speed Sorting Procedure, CACM, July 1959, p. 30-32.)
robin
| In <4bc5a414$0$78577$c30e...@exi-reader.telstra.net>, on 04/14/2010
| at 07:32 PM, "robin" <rob...@dodo.com.au> said:
|
| >I already pointed out that important algorithms were first written in
| >machine code in the 1950s
|
| I know what you claimed; you have neither substantiated it nor shown its
| relevance to the points in dispute.
Here's another example.
robin
news:alpine.LNX.2.00.1...@Bluewhite64.example.net...
| I met someone today who described himself as "an ordinary FORTRAN
| programmer" who advocated C for the practical reason that libraries
| are designed for C. He claimed that small tasks are good for multicore
| and large tasks are good for GPUs.
I think you will fnd that libraries are also designed for Fortran.
Shmuel Metz
at 08:50 PM, "robin" <rob...@dodo.com.au> said:
>Here's another example.
No.
>Don Shell published his algorithm in machine code.
No. Probably CAGE. Possibly SAP. Either you didn't read the article or
you have no idea of what machine code is.
Colin Paul Gloster
|------------------------------------------------------------------------|
|------------------------------------------------------------------------|
They certainly are. He uses code based on LAPACK. If you are aware of
Fortran bindings to GPUs which you would care to inform me of, then I
could mention to him. Maybe he already knows about them, maybe not,
but I have already informed you of the reason he gave for advocating
C.
robin
| In <4bed3524$0$67490$c30e...@exi-reader.telstra.net>, on 05/14/2010
| at 08:50 PM, "robin" <rob...@dodo.com.au> said:
|
| >Here's another example.
|
| No.
It's another example of an algorithm that was first implemented
in a language other than Algol -- -and more specifically,
in a language at a lower level than Algol.
So, the correct answer is therefore "yes".
| >Don Shell published his algorithm in machine code.
|
| No. Probably CAGE. Possibly SAP. Either you didn't read the article or
| you have no idea of what machine code is.
To be sure, I know what machine code is.
I used the term in the general sense.
Here, the intent was to point out that the algorithm was not
first implemented in Algol.
Shmuel Metz
at 07:23 PM, "robin" <rob...@dodo.com.au> said:
>It's another example of an algorithm that was first implemented in a
>language other than Algol
K3wl, David. Why do you persist in debunking claims that nobody has
made while ignoring the actual issues in dispute?
>So, the correct answer is therefore "yes".
Unfortunately it's the answer to a question that nobody asked. It's
not the correct answer to what you actually posted.
>To be sure, I know what machine code is.
The evidence suggests otherwise.
>I used the term in the general sense.
The "general sense" would have been machine language on more than just
the 704. Pointing to assembler code as an example of machine language
just makes you look less than Frank.
>Here, the intent was to point out that the algorithm was not first
>implemented in Algol.
Which is totally irrelevant to the issues in dispute.
robin
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
| In <4bf10c9c$0$89663$c30e...@exi-reader.telstra.net>, on 05/17/2010
| at 07:23 PM, "robin" <rob...@dodo.com.au> said:
|
| >It's another example of an algorithm that was first implemented in a
| >language other than Algol
|
| K3wl, David. Why do you persist in debunking claims that nobody has
| made while ignoring the actual issues in dispute?
|
| >So, the correct answer is therefore "yes".
|
| Unfortunately it's the answer to a question that nobody asked.
Go back and look at the postings. You will find that it is.
| It's not the correct answer to what you actually posted.
You are mistaken. What side of the bed did you get out of this morning?
| >To be sure, I know what machine code is.
|
| The evidence suggests otherwise.
|
| >I used the term in the general sense.
|
| The "general sense" would have been machine language on more than just
| the 704. Pointing to assembler code as an example of machine language
| just makes you look less than Frank.
|
| >Here, the intent was to point out that the algorithm was not first
| >implemented in Algol.
|
| Which is totally irrelevant to the issues in dispute.
Which it isn't. See above.
Dan Nagle
On 2010-05-17 06:26:35 -0400, Colin Paul Gloster
<Colin_Pau...@ACM.org> said:
> They certainly are. He uses code based on LAPACK. If you are aware of
> Fortran bindings to GPUs which you would care to inform me of, then I
> could mention to him. Maybe he already knows about them, maybe not,
> but I have already informed you of the reason he gave for advocating
> C.
There is a standard way of calling C functions from Fortran.
It is considered an important feature of Fortran 2003,
and is widely implemented. Therefore, the I-need-a-C-library
reason for not using Fortran is not very strong (nor is that
a very strong reason for not using Ada).
Of course, YMMV.
People make emotional decisions, and then backfill
with rational (sounding) reasons.
--
Cheers!
Dan Nagle
robin
| In <4bf10c9c$0$89663$c30e...@exi-reader.telstra.net>, on 05/17/2010
| at 07:23 PM, "robin" <rob...@dodo.com.au> said:
|
| >It's another example of an algorithm that was first implemented in a
| >language other than Algol
|
| K3wl, David. Why do you persist in debunking claims that nobody has
| made while ignoring the actual issues in dispute?
Here it is for the n-th time :-- "none" made a claim, which I disputed
because it is wrong. See below.
_________________________________________________
"none" <no...@none.net> wrote in message news:pan.2010.04.05...@none.net...
Sent: Tuesday, 6 April 2010 6:51 AM
| On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote:
|
| Dismissing Algol as ephemeral ignores its influence and continuing usage
| as a base of pseudo-codes. Important numerical libraries were first
| implemented in ALgol,
No, they were first implemented in machine code,
and later rewritten in Algol and FORTRAN.
The numerical procedures of the General Interpretive Programme
were written in machine code, from 1955.
| and later translated to Fortran when Algol's
| momentum faltered.
Richard Harter
wrote:
You appear to be misreading "Important numerical libraries were
first implemented in ALgol". The quoted text can be read in
either of two ways:
(1) "All important numerical libraries were ..."
(2) "There were important numerical libraries that were ..."
In short, the quoted text can be read either as "some" or as
"all", depending on context. The natural reading is "some".
Indeed, your "refutation" requires "some".
The general facts are that prior to the creation of fortran and
algol, almost all important numerical libraries were implemented
either in machine language or in assembly language. Afterwards
most were implemented in higher level languages.
All of that said, it is a bit misleading to say that libraries
were first implemented in Algol and later translated to Fortran.
Some were, that is true. For the most part, however, libraries
were developed independently in the two languages.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
robin
in 1954 and reprinted in 1955. It is the proceedings of
a symposium held at NPL in March 1953.
It contains reports of numeric programs being run
on various computers --
solving simultaneous equations, latent roots,
matrix multiplication, solution of Differetial equations,
partial differential equations, statistics,
computation of tables, etc.
Of course, the programs were in machine code.
That symposium was the third such held.
The previous ones were held in June 1949 and July 1951.
Shmuel Metz
at 08:58 PM, Dave Frank <rob...@dodo.com.au> said:
>Of course, the programs were in machine code.
Your saying "of course" does not make it true, or even plausible. You
keep refusing to actually provide evidence, or even independent
claims. The last time you cited something that you claimed to have
been written in machine language it turned out to have been written in
assembler.
Arthur Evans Jr
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> The last time you cited something that you claimed to have
> been written in machine language it turned out to have been written in
> assembler.
As one who was writing programs in 1957, I can assure you that the two
terms were then used interchangeably.
Art Evans
Old Codger
robin
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
news:4c0b234f$1$fuzhry+tra$mr2...@news.patriot.net...
| In <4c0a2e36$0$34205$c30e...@exi-reader.telstra.net>, on 06/05/2010
| at 08:58 PM, Dave Frank <rob...@dodo.com.au> said:
|
| >Of course, the programs were in machine code.
|
| Your saying "of course" does not make it true, or even plausible. You
| keep refusing to actually provide evidence,
What don't you understand about the publication,
"Automatic Digital Computation"?
I've given you the publisher and the date, etc.
With that information, most people can find the publication and read it.
J. Clarke
I never understood this business of making a distinction between machine
language and assembler--maybe they changed things after I stopped
working with assembler but in my day it was a 1:1 correspondence--you
knew exactly what binary each assembly language instruction would emit,
and the only practical difference was that someone who didn't have an
idiot-savant ability to remember numerical codes could learn to work in
assembler in a reasonable time.
Perhaps he's looking for programs in microcode or something.
J. Clarke
> In<4c0a2e36$0$34205$c30e...@exi-reader.telstra.net>, on 06/05/2010
> at 08:58 PM, Dave Frank<rob...@dodo.com.au> said:
>
>> Of course, the programs were in machine code.
>
> Your saying "of course" does not make it true, or even plausible. You
> keep refusing to actually provide evidence, or even independent
> claims. The last time you cited something that you claimed to have
> been written in machine language it turned out to have been written in
> assembler.
What do you believe to be the difference between machine code and assembler?
Simon Wright
Perhaps he means they look different :-)
Ferranti's Fixed-Point AutoCode: v1 = v2 + v3
Binary: 000 01 0 000 00001 00010 00011
Spoken as: 0110 1 2 3
Clearly not the same at all!!!
glen herrmannsfeldt
Unless you are actually doing it. There are stories from the early
days of S/360 about patching object decks by adding cards.
As each card has a starting address and length, you could easily
patch a few bytes by punching a new card with the appropriate
bytes and adding it later in the object deck. In that case,
one might actually try to keep the distinction.
Otherwise, I agree.
-- glen
Martin Krischik
6502 Assembler:
LDA #10
6502 Machine code:
A9 10
Any more silly questions?
Martin
--
Martin Krischik
mailto://kris...@users.sourceforge.net
https://sourceforge.net/users/krischik
Martin Krischik
> In article <4c0b234f$1$fuzhry+tra$mr2...@news.patriot.net>,
> As one who was writing programs in 1957, I can assure you that the two
> terms were then used interchangeably.
They where not in the '80 any more.
J. Clarke
Yeah. On a 360 that would be two steps (there isn't an instruction to
add two registers and put the result in a third):
LR 1,2
AR 1,3
Binary 00011000 0001 0010
00011010 0001 0011
Non scrivetemi
I don't know what happened up to that point, but I can assure you that the
two terms were not used interchangably after 1957. Assembler is *not*
machine language.
J. Clarke
The main distinction for me was that dumps don't come out in assembler.
But I never thought of machine code and assembler being distinct as a
result--just two ways to write the same thing.
J. Clarke
> Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
>
>> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
>
>> What do you believe to be the difference between machine code and
>> assembler?
>
> 6502 Assembler:
>
> LDA #10
>
> 6502 Machine code:
>
> A9 10
>
> Any more silly questions?
Does LDA #10 assemble to any _other_ code than A9 10? Is there any
_other_ code that assembles to A9 10? If the answer to both is "no"
then in what significant way are they different?
John B. Matthews
"J. Clarke" <jclarke...@cox.net> wrote:
> On 6/6/2010 1:15 PM, Martin Krischik wrote:
> > Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
> >
> >> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
> >
> >> What do you believe to be the difference between machine code and
> >> assembler?
> >
> > 6502 Assembler:
> >
> > LDA #10
> >
> > 6502 Machine code:
> >
> > A9 10
> >
> > Any more silly questions?
>
> Does LDA #10 assemble to any _other_ code than A9 10?
Yes, but it depends on the assembler: I have two that generate A9 10,
and the rest produce A9 0A.
> Is there any _other_ code that assembles to A9 10?
Yes, but they (trivially) involve a macro, expression or radix.
> If the answer to both is "no" then in what significant way are
> they different?
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Gib Bogle
> Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
>
>> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
>
>> What do you believe to be the difference between machine code and
>> assembler?
>
> 6502 Assembler:
>
> LDA #10
>
> 6502 Machine code:
>
> A9 10
>
> Any more silly questions?
Yes. What relevance does this have for Fortran?
J. Clarke
None at all, but it's fun to torment the "I program in machine code
because it gives me more control than assembler" crowd.
J. Clarke
> In article<hugt0...@news2.newsguy.com>,
> "J. Clarke"<jclarke...@cox.net> wrote:
>
>> On 6/6/2010 1:15 PM, Martin Krischik wrote:
>>> Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke<jclarke...@cox.net>:
>>>
>>>> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
>>>
>>>> What do you believe to be the difference between machine code and
>>>> assembler?
>>>
>>> 6502 Assembler:
>>>
>>> LDA #10
>>>
>>> 6502 Machine code:
>>>
>>> A9 10
>>>
>>> Any more silly questions?
>>
>> Does LDA #10 assemble to any _other_ code than A9 10?
>
> Yes, but it depends on the assembler: I have two that generate A9 10,
> and the rest produce A9 0A.
So pick one and answer about that one instead of waffling.
>> Is there any _other_ code that assembles to A9 10?
>
> Yes, but they (trivially) involve a macro, expression or radix.
Not "code" in the sense of "program", "code" in the sense of "mnemonic
opcode".
Martin Krischik
Maybe the talk about one of those advanced *macro* assemblers ;-). Now
that is a different story.
Martin Krischik
<g.b...@auckland.no.spam.ac.nz>:
None. I was just answering the question. And loking on the cross post list
I am wondering what the question did here in the first place.
Martin Krischik
> On 6/6/2010 1:15 PM, Martin Krischik wrote:
>> Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
>>
>>> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
>>
>>> What do you believe to be the difference between machine code and
>>> assembler?
>>
>> 6502 Assembler:
>>
>> LDA #10
>>
>> 6502 Machine code:
>>
>> A9 10
>>
>> Any more silly questions?
>
> Does LDA #10 assemble to any _other_ code than A9 10?
No.
> Is there any _other_ code that assembles to A9 10?
Yes:
.BYTE $A9, $10
or:
Ten: .EQ $10
LDA #Ten
Did you all forget that assemblers support symbolic names, various pseudo
codes and sometimes macros? That was the really useful part.
robin
| "J. Clarke" <jclarke...@cox.net> writes:
|
| > What do you believe to be the difference between machine code and assembler?
|
| Perhaps he means they look different :-)
|
| Ferranti's Fixed-Point AutoCode: v1 = v2 + v3
| Binary: 000 01 0 000 00001 00010 00011
| Spoken as: 0110 1 2 3
Pegasus Autocode was not developed until 1956-57.
Pegasus Mark I Autocode was available from mid-1954.
(Lavington, The Pegasus Story, 2000, p. 35).
Anyway, the point I was making was that the programs
were run before the March 1953 Symposium,
and that the programs preceded FORTRAN, and preceded ALGOL.
robin
| Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
|
| > On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
|
| > What do you believe to be the difference between machine code and
| > assembler?
|
| 6502 Assembler:
|
| LDA #10
|
| 6502 Machine code:
|
| A9 10
|
| Any more silly questions?
That assembler was of a much later period than the one under discussion,
namely, the 1940s-1950s.
Peter Flass
> Am 07.06.2010, 02:18 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
>
>> On 6/6/2010 7:01 PM, Gib Bogle wrote:
>>> Martin Krischik wrote:
>>>> Am 06.06.2010, 17:19 Uhr, schrieb J. Clarke <jclarke...@cox.net>:
>>>>
>>>>> On 6/6/2010 12:25 AM, Shmuel (Seymour J.) Metz wrote:
>>>>
>>>>> What do you believe to be the difference between machine code and
>>>>> assembler?
>>>>
>>>> 6502 Assembler:
>>>>
>>>> LDA #10
>>>>
>>>> 6502 Machine code:
>>>>
>>>> A9 10
>>>>
>>>> Any more silly questions?
>>>
>>> Yes. What relevance does this have for Fortran?
>>
>> None at all, but it's fun to torment the "I program in machine code
>> because it gives me more control than assembler" crowd.
>
> Maybe the talk about one of those advanced *macro* assemblers ;-). Now
> that is a different story.
>
Of course that's effectively two programs - a macro processor and an
assembler. The PL/I preprocessor isn't tied to the language and can be
used as a general-purpose macro processor.
Peter Flass
If you want to talk *really* old assemblers, look at SOAP. The hardware
had no core, only drum memory, and each H/W instruction contained the
drum address of the next instruction to be executed. A big function of
the assembler was figuring out where to store the instructions on the
drum so that the next instruction was under the R/W head just as the
previous finished executing -- based on the instruction timings. Try
doing that by hand for a large program!
Yannick Duchêne (Hibou57)
écrit:
> If you want to talk *really* old assemblers, look at SOAP. The hardware
> had no core, only drum memory,
--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.
J. Clarke
> In<hugev...@news5.newsguy.com>, on 06/06/2010
> at 11:15 AM, "J. Clarke"<jclarke...@cox.net> said:
>
>> I never understood this business of making a distinction between
>> machine language and assembler
>
> optimization.
If it "optimizes" then it's not an assembler, no matter what it might be
called.
>> maybe they changed things after I stopped
>> working with assembler but in my day it was a 1:1 correspondence
>
> Not by 1960. Even before the macro era you had pseudo-ops that emitted
> no code and pseudo-ops that generated multiple words.
So? Shortcuts to keep from having to repeatedly type a bunch of code.
Don't do anything you couldn't do by hand and you are not compelled to
use them.
>> and the only practical difference was that someone who didn't have
>> an idiot-savant ability to remember numerical codes could learn to
>> work in assembler in a reasonable time.
>
> Maintaining your own symbol table would be labor intensive unless
> you're JvN; I vaguely recall that he refused to use assemblers.
He came down with cancer around the time that assemblers started to
become common, too, and died shortly after, so one has to question the
relevance of such an observation.
>
>> Perhaps he's looking for programs in microcode or something.
>
> ?
>
> FWIW, IBM used assemblers for the ROS on the S/360 and S/370; I don't
> know about other vendors.
J. Clarke
> Le Mon, 07 Jun 2010 12:40:07 +0200, Peter Flass <Peter...@yahoo.com>
> a écrit:
>> If you want to talk *really* old assemblers, look at SOAP. The
>> hardware had no core, only drum memory,
> What is a “drum memory” ?
Are you serious?
You remember those old Edison phonographs that used a wax cylinder?
Well imagine that concept only with the cylinder coated with magnetic
material instead of wax, and with a row (or several rows) of heads along
its length. Has most of the properties of a fixed-head disk except the
unequal track lengths.
Arthur Evans Jr
Peter Flass <Peter...@Yahoo.com> wrote:
> If you want to talk *really* old assemblers, look at SOAP. The hardware
> had no core, only drum memory, and each H/W instruction contained the
> drum address of the next instruction to be executed. A big function of
> the assembler was figuring out where to store the instructions on the
> drum so that the next instruction was under the R/W head just as the
> previous finished executing -- based on the instruction timings. Try
> doing that by hand for a large program!
SOAP was an assembler for the IBM 650, a drum machine that had 200 (NOT
2048) words on a rotating drum in 40 tracks of 50 words each. It was a
one-plus-one address machine, each instruction including the address of
its successor.
As Mt Flass has said, SOAP (Symbolic Optimal Assembler Program) did its
best to place each instruction so that it was coming under the read
heads when the previous instruction finished executing.
But, it did that when first the instruction was encountered in the
input. If the instruction was the successor of another instruction, it
wasn't likely to be optimized for this one. Thus it was in fact
sometimes (rarely) worth doing that optimization by hand for frequently
used pieces of code.
The 650 initially had no floating point instructions, so the run time
support library for IT included code to simulate floating point
arithmetic. Since this package had heavy use, my colleague Joe Smith
optimized it by hand, resulting in a noticeable performance increase.
Yes, I know, this discussion really belongs on alt.folklore.computers,
but I couldn't resist.
BTW -- Don Knuth, who like me cut his programming teeth on the 650, once
designed an integer-programming application to truly optimize
instruction placement. I don't know if he ever actually programmed it,
as he was sure it would take vastly more time to execute than it could
ever save. I may misremember some of the details.
Art Evans
Old Codger
robin
| If you want to talk *really* old assemblers, look at SOAP. The hardware
| had no core, only drum memory, and each H/W instruction contained the
| drum address of the next instruction to be executed. A big function of
| the assembler was figuring out where to store the instructions on the
| drum so that the next instruction was under the R/W head just as the
| previous finished executing -- based on the instruction timings. Try
| doing that by hand for a large program!
That was done by hand for many early machines that relied on
mercury delay line (or nickel) memories.
Some of those progrems were gigantic.
Nevertheless, done in stages (building blocks)
it was managable.