installing an OS from source on fresh machine and some other questions
rlc
embarrassed asking it in class, so I'll ask it here..
Say for instance I have a fresh IA-32 machine without anything on
it(besides I suppose the rom) and I have the source code for an
operating system, minix or whatever, and I have the binary of a
compiler.
As is probably evident from these questions my understanding is
tragically sparse :) If anyone has the energy for a thorough reply,
believe me it would be very much appreciated.
1) How do I get the compiler binary on the machine so that I can
compile the source? I assume it would have to be something like
creating a bootable cd or something. I know that the rom reads a
certain address from the media at bootup, so how do I ensure that the
compiler is at this correct address on the media? Also, if I only
have a compiler, how do I interact with it to compile the sources if I
have no shell or i/o drivers? Would I just have to write another
script to compile everything in batch mode?
2) A second hypothetical: If I have an operating system written
entirely in assembly for my ISA, would all that I have to do is put
the first startup script at the designated place in memory that the
rom reads and then point to the location of other assembly files as
needed?
Thanks
Robert Cloud
rcloud [at] gmail [dot] com
J.F. de Smit
> Ok guys, this is a really noobish question, and I feel kind of
> embarrassed asking it in class, so I'll ask it here..
> Say for instance I have a fresh IA-32 machine without anything on
> it(besides I suppose the rom) and I have the source code for an
> operating system, minix or whatever, and I have the binary of a
> compiler.
These three items alone are (unfortunately) simply not enough to get your
machine up and running. To compile your source code you will need a way to
read it and write the compiled binary to some location, at the very least.
This means you will need some sort of medium access routines that a
compiler does not have built in. In other words: you need an OS to run
your compiler. I'll continue answering your questions below.
> As is probably evident from these questions my understanding is
> tragically sparse :) If anyone has the energy for a thorough reply,
> believe me it would be very much appreciated.
> 1) How do I get the compiler binary on the machine so that I can
> compile the source? I assume it would have to be something like
> creating a bootable cd or something. I know that the rom reads a
> certain address from the media at bootup, so how do I ensure that the
> compiler is at this correct address on the media? Also, if I only
> have a compiler, how do I interact with it to compile the sources if I
> have no shell or i/o drivers? Would I just have to write another
> script to compile everything in batch mode?
Okay, you've touched upon the problem already: you don't have a shell or
I/O drivers. The former is a pain, the latter will make your endeavour
imposible (unless you decide to write a compiler that also contains i/o
drivers and everything, but that basically means you're creating an OS
that has a built-in compiler...). A script is not going to help you
either, because scripts are interpreted by the shell, which you don't
have. What you need is a compiled operating system to compile your
operating system: a classic bootstrapping problem that is (fortunately)
easily solved by the sheer abundance of operating systems these days. What
you need to do is install Minix on a PC (using a Live CD that you can
download from the Minix 3 site), compile your sources into a boot image
and use the utilities that you can find in the Minix 3 Subversion
repository to put your boot image, supporting files and the boot monitor
into an image that you can then burn to a bootable CD-ROM.
> 2) A second hypothetical: If I have an operating system written
> entirely in assembly for my ISA, would all that I have to do is put
> the first startup script at the designated place in memory that the
> rom reads and then point to the location of other assembly files as
> needed?
Yes, this is called bootstrapping the machine: the designated region
contains enough code to read a more complex program from the medium,
execute that which can then do more complex stuff (because it can be
larger), and so forth (if necessary) until you have the operating system
you want.
Regards,
Jens
--
Jens de Smit
Student Computer Science | Vrije Universiteit Amsterdam
jfd...@few.vu.nl | http://www.few.vu.nl/~jfdsmit
"[In the end, people] get furious at IT that the goddamn magic isn't working"
-- Stewart Dean
Erik van der Kouwe
> > entirely in assembly for my ISA, would all that I have to do is put
> > the first startup script at the designated place in memory that the
> > rom reads and then point to the location of other assembly files as
> > needed?
>
> Yes, this is called bootstrapping the machine: the designated region
> contains enough code to read a more complex program from the medium,
> execute that which can then do more complex stuff (because it can be
> larger), and so forth (if necessary) until you have the operating
> system you want.
This may be nitpicking, but I hope that maybe it does clarify something
for OP: CPUs do not execute assembly, but rather machine code. Assembly
is the closest thing there is to human-readable machine code, but it is
not the same thing. Assembly consists of mnemonics with operands which
mostly map one-to-one with opcodes the CPU understands. The former,
however, is text encoded in some way (ASCII, EBCDIC, Unicode, ...)
while the latter is pure binary.
To convert assembly into an executable program an assembler is needed,
or someone has to convert it manually. This is tedious, but I suppose
this was needed to create the first assembler, which in turn may have
been used to assemble the first compiler. Writing machine code directly
is not to be recommended.
--
With kind regards,
Erik van der Kouwe
J.F. de Smit
> To convert assembly into an executable program an assembler is needed,
> or someone has to convert it manually. This is tedious, but I suppose
> this was needed to create the first assembler, which in turn may have
> been used to assemble the first compiler. Writing machine code directly
> is not to be recommended.
Going off-topic....
Manually converting assembly was actually very common in "the early days".
Way back when, computers were huge devices, usually needing one or several
rooms all in all. The machines were batch-operated and users had to turn
in their program (punched into punch cards) to the operator, who would
later load up and run their program. Computers were in such high demand
(and so expensive to operate) that performing such frivolities as
"compiling your program on the computer" was out of the question: the
program you turned in had to be machine code already. Therefore,
programmers first wrote their program in assembly language and then, using
the assembly table, convert their program into opcodes and operands before
punching it into the cards. Unimaginable in this day and age, but it
happened...
Robert Cloud
hiding somewhere in rom, so its good to clear this up.
If I were to put machine code on the first sector of a disk, would it
be read and executed at bootup?
Robert Cloud
Erik van der Kouwe
Henk Robbers
> Thanks for the replies. I had always thought there was an assembler
> hiding somewhere in rom, so its good to clear this up.
>
Your assumption is justifiable.
It has been done in the past.
1985 Atari ST; OS with graphical user interface in ROM.
Slightly later: Acorn RISC OS: Graphical user interface including
BASIC interpreter in ROM. The BASIC also included a assembler and could
be used in commandline or batch mode.
You could do usefull things with these computers without the need of
a (usable) hard disc.
Only very recently there have been attempts to provide something similar
for x86. Flashable Linux in the BIOS roms.
A flashable Minix would be nice.
--
Groeten; Regards.
Henk Robbers.
Michael Black
You have to know the hardware.
Back when computers had front panel switches, or even just simple monitors
in ROM, you'd enter a bit of code that would be the bare minimum to load
in a bit of code drom some storage medium (be it paper tape or audio
cassette). It would be a bare minimum since you didn't want to type in or
flip switches much every time you turned on the computer. So usually the
bit of code that gets loaded would actually be a fancier loader program
that would load more than a bare minimum.
Later, the firmware in ROM got more complicated, and did the initial work.
What you need depends on the hardware.
For an "IBM Compatible" type computer, it's pretty well documented what is
needed, code stored at a certain point on a disk, and the code has to have
the proper "signature" so the bootloader knows it's executable code rather
than some random sector, and the code has to load at a specific location
in memory. Once the sector is loaded, the firmware will execute it
starting at a specific location.
The code can be anything so long as it's short enough and meets the
requirements. It can be a really simple program (simple since you don't
have much space), or it can be code to load more sectors and then execute
it, and that more code can be a standalone program, something that uses
the BIOS routines, or some full blown operating system.
Michael
frank87
> Robert Cloud wrote:
>> Thanks for the replies. I had always thought there was an assembler
>> hiding somewhere in rom, so its good to clear this up.
>>
>
> Your assumption is justifiable.
> It has been done in the past.
>
> 1985 Atari ST; OS with graphical user interface in ROM.
> Slightly later: Acorn RISC OS: Graphical user interface including
> BASIC interpreter in ROM. The BASIC also included a assembler and could
> be used in commandline or batch mode.
In home-computer-days it way custom that some kind of prompt showed up
when you started the computer. It was possible to enter your code (most
often in HEX-numbers or basic).
Greetings,
Frank
Michael Black
> "Erik van der Kouwe" <vdkouwe <at> few.vu.nl> wrote:
>> To convert assembly into an executable program an assembler is needed,
>> or someone has to convert it manually. This is tedious, but I suppose
>> this was needed to create the first assembler, which in turn may have
>> been used to assemble the first compiler. Writing machine code directly
>> is not to be recommended.
>
> Going off-topic....
>
> Manually converting assembly was actually very common in "the early days".
> Way back when, computers were huge devices, usually needing one or several
> rooms all in all. The machines were batch-operated and users had to turn
> in their program (punched into punch cards) to the operator, who would
> later load up and run their program. Computers were in such high demand
> (and so expensive to operate) that performing such frivolities as
> "compiling your program on the computer" was out of the question: the
> program you turned in had to be machine code already. Therefore,
> programmers first wrote their program in assembly language and then, using
> the assembly table, convert their program into opcodes and operands before
> punching it into the cards. Unimaginable in this day and age, but it
> happened...
>
And those early computers had relatively little space, be it "RAM" or
long term storage. An assembler might have been too big.
And of course, "assembly language" is more a symbolic system for making
machine language easier.
In the old days, the CPUs were much simpler, and it was fairly easy to
remember the common op-codes. The addressing modes were also relatively
simple, so it was easy to figure out the operands. I started with a 6502
back in 1979, and I never used an assembler in the 5 years I used
6502-based computers. I got used to the commonly used op-codes, and the
only "complication" was figuring out the relative branches (all 8bit), but
I copied a chart out of a magazine for that.
Yes, I used "assembly language" to plan it out, it was easier to visualize
what was going on and of course place to add comments, but it really took
little effort to assemble it all.
When I moved to a 6809-based computer, I had to get an assembler. The
instruction set was much richer, as were the addressing modes, and it took
too much effort to keep track of it all.
Michael
rcl...@localhost.localdomain
to use these early computers. My earliest memories as a child were playing
with a tandy 386 sometime around 1990 I think, and it was pretty apparent
that we were on the cusp of a decadent new age when we got access to
Compuserve a few years later.
I've never seen a punch card, i've never seen a tty, or
a minicomputer, much less one of those archaic beasts which you must
tickle(read: toggle) to get some work done, so really trying to understand
what using these was like is difficult for me.
Regarding these toggle machines,
Were the switches simply
binary patterns? When you say you would enter just enough code to get the
computer to load from another device, I'm assuming that you would actually
have to write a driver with those toggling switches as well as point to
the memory address and the machine code for read or whatever. Yes?
So theoretically I could use my computer like one of the early batch
machines if I were to use a CD as a rather large punch card. Excellent.
Robert Cloud
Undergraduate Student
University of Alabama at Birmingham, USA
Skype! rcloud86
rcl...@gmail.com
rcl...@cis.uab.edu
Fred J. Scipione
<rcl...@localhost.localdomain> wrote in message
news:Pine.LNX.4.64.08...@localhost.localdomain...
If you have an interest in getting some 'hands-on' experience for
early home computers, you could try an emulator like the Altair
emulator at http://www.altair32.com/. It has copies of the
documentation and early software. The Altair emulator uses
a graphical interface that will let you flip switches and feed
paper tape or audio tape (image files). The emulator can be
run in a 'bare-bones' set-up, or decked-out with floppy drives
to run an 'advanced' OS like CP/M 2.2!
Robert Cloud
> If you have an interest in getting some 'hands-on' experience for
> early home computers, you could try an emulator like the Altair
> emulator at http://www.altair32.com/. It has copies of the
> documentation and early software. The Altair emulator uses
> a graphical interface that will let you flip switches and feed
> paper tape or audio tape (image files). The emulator can be
> run in a 'bare-bones' set-up, or decked-out with floppy drives
> to run an 'advanced' OS like CP/M 2.2!
I'd like to thank you for this suggestion. I've been playing with
the Altair emulator for the last few days and I definately feel that it
has helped
me come to some more concrete terms with my understanding of computers
and memory systems.
I've been messing around with some simple arithmetic programs.
I really cannot understand how people got from point A, that is
arithmetic programs with byte representations of binary digits, to
early operating systems, point B, if all a computer can do is store
binary data in a memory location and perform arithmetic operations on it.