On 20 Dec 2000, at 14:00, Ben A L Jemmett wrote:
> > Well, when I said that its possible to make a compiler that would
> > make ROMs instead of ELF I thought that the library porting part would
> > be obvious..
> Uhr, so you adjust the compiler (or more specifically, the linker -
> compilers spit out the same code for any given processor, mode and memory
> model) to use a ported library, which requires a ported OS, so we're back
> where we started?
>
> Regards,
> Ben A L Jemmett.
> (http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)
Almost, but not quite.
The way the scenario works is that you write code for your target
platform (i.e. the Dreamcast, or other similar system). You run the
code through the compiler, which, when told to target the
processor in the target system, spits out machine code appropriate
to your target processor. The linker stitches that code together
with the libraries that you've used - libraries that are coded for the
target platform.
The key is the libraries. You don't need an OS on the target
platform, if the libraries will take care of the nitty-gritty for you.
Sometimes they don't, and you need to code it directly into your
code that you feed into the compiler.
For example, on the IBM PC platform, in DOS, many of the I/O
calls use the code already in the BIOS to work. So when you write
a "print" statement in your code, the compiler translates that into a
call to the "print" function in the libraries. In the library is a pre-
compiled bit of code which (for the PC/DOS/BIOS combo) uses
some of the BIOS calls to output the values of the arguments.
Those BIOS calls are the ones which actually do the work, by
moving bytes around, sending them to the video I/O ports or writing
them to the appropriate memory areas.
Now, your target platform does not have the PC BIOS. It may not
even have one at all, in some cases. So, what happens is that in
the library, the "print" function is implemented not by BIOS calls,
but by code that, for the PC, would be in the BIOS. This code
does the actual I/O work, putting bytes into the I/O ports of the
video subsystem.
So, your libraries are the key. A given library targets a specific
processor, with specific assumptions about what the OS is...
including the assumption that there is no OS at all.
Once you've run through this process, then you've got a piece of
code to run on the target system. At that point, you need to get
that code to the target system, to test it, or run it through an
emulator on your host system [the PC] to test your code for the
target.
It used to be that you would burn your code to an EPROM, then
stick that in the target system for testing. Now, it's likely that
there's an emulator that you can use to simulate the execution of
the code, with lots of debugging features to speed code
development.
Hope this makes the process clearer,
Anthony J. Albert
==============================================================
Anthony J. Albert [EMAIL PROTECTED]
Systems and Software Support Specialist Postmaster
Computer Services - University of Maine, Presque Isle
"We took risks. We knew we took them. Things have come out against
us. We have no cause for complaint." - Explorer Robert Scott, found in
his diary after his party froze to death in Antarctica.
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
