ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Just to show my age, when I was a graduate student at Columbia University, I "amazed" some of my fellow students by programming an IBM 407 (IIRC) punched-card reader, using a plugboard, to calculate sums and products needed for a ANOVA homework problem directly from the data cards. Thus solving the exercise without needing any time on the mainframe (IBM 7094) computer, for which I'd have had to wait several days.
<edit>
Oh, and don't forget Ada Lovelace, who programmed the "difference engine" in the 19th century.
</edit>
Last edited by PTrenholme; 08-09-2013 at 03:45 PM.
I just came across a really nice text that explains a lot of this a couple weeks ago, its called "Linux Assembly Language Programming" by Bob Neveln, Prentice-Hall 2000. It explains all of this stuff to a beginner. I think you would understand much more and be able to write basic machine code programs if you read it, I'm learning a lot.
A stored-program computer, with the program stored in hardware (removable plugboard with jumpers) rather than stored in the computer's writeable memory.
IBM Pipelines (a/k/a Hartmann Pipelines) are what Unix pipelines could be, should be, and may someday actually be. Loops, branches, etc.
The IBM 407 still lives! When I retired (1994) 407 Emulation was a new feature of IBM Pipelines. I presume it is still there and now perfected.
"because humans cannot write machine language directly"
Of course we can and I have done so several times in my life. The first machine that I did it on was an IBM 1440 which was an octal machine. I used the toggle switches on the console to enter and execute the program. I think that was in 1966.
"not to think about a compiler). So how was that made?"
The first step was that assemblers were written in machine language. An assembler has a one to one correspondence between an assembly instruction and a machine op code. Then macros were added to assemblers. A macro was an instruction like READ which the assembler expanded into several assembly instructions which it assembled on the next pass. The first compilers were assemblers with a good enough set of macros that you could write a program entirely in macros without having to intersperse any assembly instructions.
Then the ALGOL and FORTRAN languages were invented followed a year or two later by COBOL. The first compilers generated assembly code which was fed into an assembler. Later the early compilers were improved to generate machine code directly without going through an assembler pass.
Legend has it that Seymour Cray booted the first Cray-1 by setting switches manually on the front ctrl panel
As mentioned above, basically, you write the shortest simplest code you can in binary (asm if you're lucky) to load a slightly smarter program that eg then reads a punched card machine that has the OS card stack in it... that's how it used to be done way back when (see also paper tape )
Great thread! I am glad to see that there are lots of programmers who have entered programs in binary by toggle switches on the front panel. I did a bit of that, way back around 1976.
To answer the question
"How was the first program ever written"
one must go back to at least the Egyptians (recorded) or sooner.
The answer was on papyrus.
Because a Program is a process to follow with if's and then's.
If this thing has been completed then do something.
It was a logical process to use electronics to help with the decisions.
Hard wired programs (first written on paper )
were used with cam switches and relays (example' the Traffic lights First used 1868 in London)
Even before this with punched card to operate looms and musical instruments. (Not Electrical)
Hard wired programs again from paper was used at Bletchley Park decoding German war messages (WW2).
Flow diagrams are still used in some establishments and have to be proved before the are used on a machine.
I feel it is sad that the History of programing is not often taught prior to Programing courses.
To answer the question
"How was the first program ever written" one must go back to at least the Egyptians[...]
Hey, don't forget the Sumerians: There's at least one example in Cuneiform of a clay tablet of procedures for finding the area of a plot that precedes all the Egyptian dynasties.
And, if you want to include automated music, the "music box" is, I think, a fairly old device.
But the essence here is: "What did the OP mean by "program?"
If the meaning was "an automatically processed set of instructions to a mechanical device, where different instruction sets could be used" then the written algorithms for people to implement are "off the table." (Although I should note that there is little logical difference between a set of instructions for a person to implement and the same set of instructions for a mechanical device to implement. Take, for example, the Jacquard loom where complex woven cloth can be produced from a "program" written in the set of punched cards processed by the loom, and, of course, the same cloth could be produced by a person from the same written instructions used to produce the punched cards.)
Perhaps the OP could clarify what was meant by "program" in the question?
But the essence here is: "What did the OP mean by "program?"
I believe what the Op meant by "program" is explained in the body of his post.
Quote:
Originally Posted by thelinuxist
after learning some programming languages, I got to philosophizing a bit. The first python interpreter was written in C (I think?) and the first C compiler was written in ASM. But in which language was the first assembler written?
That's what I don't understand, because humans cannot write machine language directly (Can anyone? Looking at binary files opened with less, I don't think anyone could understand or even write even a simple app that way - not to think about a compiler).
He was asking about computer machine language programs. He wanted to know how the first symbolic assembler program was written. He didn't think it was possible for anyone to write a program directly in machine language.
Many of the replies in this thread are answering the question in the subject of the post rather than the question in the body of the post. These replies often assume a more general meaning of the word "program" than what the Op clearly intended.
[...]He didn't think it was possible for anyone to write a program directly in machine language.[...]
Ah so.
Well, as several respondents pointed out, it's hard, but not impossible. (As one noted above, assembly language can be mapped, one-to-one, to binary machine language.)
A number of years ago, one of my programs crashed the IBM 7094 computer at Columbia University, and I was presented a core dump and told to "fix" my program before I was allowed to run any new programs. (I was a graduate student there at the time, so I was assumed to have caused the problem.) I had to go through several hundred pages of binary dump trying to find the cause. I finally discovered a bit that was a 1 that should have been a 0 that created an invalid instruction causing the crash. After further investigation, I concluded that a "cosmic ray" (or other "act of god") had flipped the bit. When I presented my conclusion to my advisor, he told me that it wasn't too uncommon: the magnetic ring memory used for RAM at that time was subject to instability.
My point is that, even as late as the 1960's, a computer programmer was expected to be able to read and understand binary.
Even today a computer forensic analyst often needs to be able to understand what's happening at the bit-by-bit level.
So, bottom line, the OP's premise that "it was [im]possible for anyone to write a program directly in machine language" is, clearly, incorrect.
Now that you mention it, I believe it may have been, or hex; and the location of the invalid instruction was flagged. But it still took me a while, and it's the only bug I've ever traced to an actual bit fip. (Although, IIRC, the original "bug" was a moth, but that was before my time.)
In reply to
""That's what I don't understand, because humans cannot write machine language directly (Can anyone? Looking at binary files opened with less, I don't think anyone could understand or even write even a simple app that way - not to think about a compiler.""
In the Eighty's my head programer Not only could but regular programed directly Intel 8080 and Zilog Z80 code as well as calculate address of sets and entered them direct using binary push buttons.
He was quite good in Motorola 6500 code but a little slower.
He was writing a bios, basic interpreter and later a Z80 compiler.
All programs written and proved on paper first!
In his spare time he wrote a assembler.
Was this unusual, absolutely not all the Graduates From Bristol University(UK) Computer Science Course could do it.
I dare say the same from any other University.
As for me no I am a hardware man.
Trevor
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.