| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 659.1 | Good idea! Could we discuss the specific problems here? | ISTG::WISNER | Paul Wisner | Thu Aug 20 1987 17:37 | 24 |
| Greate idea!
I believe the only other cross compiler is SUN based, or is it Apollo?
I wonder if a VAX 2000-BASED cross-compiler would be competitive
with the other cross-compiler in terms of price/performance for
non-DEC employees.
Of course, with the Employee purchase plan, you couldn't beat it.
My (mis)understanding of linkers:
All a linker does is fill in addresses for unresolved symbol references
and then write out the executable code. Each object file has a
symbol table, and then machine instructions, occassionally interupted
by an unresolved symbol references (a symbol name).
How do you propose to handle the differences in the instruction
sets?
Paul Wisner
|
| 659.2 | silly questions\ | ARKHAM::WHERRY | Servant of Cthulhu | Thu Aug 20 1987 18:38 | 26 |
|
First off, ya'll have to excuse my ignorance where it shows...
>I believe the only other cross compiler is SUN based, or is it Apollo?
It is SUN-based.
If you are creating/developing a cross-development environment,
then that means to me that compiles and links take place on a
machine which already has an operating system which is debugged,
robust etc.. This is being done for one of two reasons, the target
machine does not have a native environment suitable to doing this
work (like building the target machines operating system), or the
amount of time that can be saved by compiling and linking on another
machine is worth it.
Are there any PD compilers (in a high level language c m2 ada etc)
which you plan to port to the vax, making the appropriate changes
in instruction sets (ie: if the compiler was originally for a 8086),
or are you gonna write this from scratch...
Are there any PD linkers etc. etc.
(the above two questions assume the source code is available).
brad
|
| 659.3 | | ANGORA::SMCAFEE | Steve McAfee | Thu Aug 20 1987 20:37 | 23 |
|
re: existing cross compilers
There is a PC based version cross-compiler. Supposedly this is
what EA uses to develop all their software.
re: cross compiling on the vax
This really cannot be done effectively without a 68000 compiler.
Translating VAX instructions to 68000 just isn't feasible. Most
likely, there is a PD 68000 assembler that runs on a VAX out there
somewhere, but I'm not so sure about a C compiler. If you find
a compiler then you will find a linker with it so that would solve
both problems. You might want to post a note in some of the other
68000 based notes files.
Come to think of it there is probably source to a 68000 assembler
on one of the fish disks. It might be interesting to port this
to the VAX.
regards,
steve mcafee
|
| 659.4 | the rocks of reality | ISTG::WISNER | Paul Wisner | Thu Aug 20 1987 21:57 | 10 |
| There is a switch in the c compiler to produce assembly. I'd assume
this is true for VAX C. VAX assembly (MACRO) could be easily
translated into 68000 assembly. It's starting to get complicated.
It's dissapointing that it's ot feasable to translate VAX instructions
to 68000. (I'm still not convinced, completly, can you give a
convincing argument?)
The SUN uses a 68000 right?
|
| 659.5 | What's the goal ?? | ELWOOD::PETERS | | Fri Aug 21 1987 02:14 | 23 |
|
Why would anyone want to develop AMIGA software on a VAX ???
In my work with DEC I have used VAX based tools to write
firmware for 68000 based controllers. We have C compilers, linkers,
and assemblers. We can even emulate 68000 systems on the VAX.
I also have written code on the AMIGA. Any speed gained doing
compiles and links on a VAX will be lost moving code from the
VAX to the AMIGA.
The only thing that might make any sense is to move the AMIGA
include files to a VAX and create dummy routines so that C source
can be compiled and linked on a VAX using VAX C. This way programs
can be entered on a VAX and compile time errors could be fixed.
I don't think this has much if any advantage over developing code
on the AMIGA.
Steve Peters
Tape Eng.
|
| 659.6 | re .4 | ARKHAM::WHERRY | Servant of Cthulhu | Fri Aug 21 1987 13:29 | 8 |
| re .4
Yes, they are 68000 based, although I do not believe that they
sell any more 68000 machines, they are all 68020 with FPU's and
MMU's...We have a couple of "low end" sun's at school, and they
all have the above.
brad
|
| 659.7 | | PLDVAX::SMCAFEE | Steve McAfee | Fri Aug 21 1987 13:36 | 38 |
| re .4
Problems with porting code at assembly level:
Once you get to the assembly level, portability in general is largely
restricted. All those nice portable C routines, like STDIO, have
been resolved into code which is specific to the machine the compiler
was intended for. I'm not saying the STDIO routines are in the
object module, they're not, but calling sequences are.
Numbers on the VAX are stored from most significant byte down to
least significant byte (vica-versa on the amiga). This means any
constants in the code would have to be twiddled (I suppose the linker
could do this however).
The VAX instruction set may not map directly into the 68000's.
It may seem that this is not that big a deal because we can probably
do any VAX instruction with two 68000 instructions. However, once
we start doing this, we may have to keep track of registers and
such in case one of our instruction maps need a "temporary". Now
we're talking about more of a assembler/compiler than a translator.
I don't mean to say this is impossible. I just think it would be very
difficult to implement.
re .5
If .5 has a C compiler and linker, then all you have to do is upload
those C includes and your all set.
I might be interested in accessing this. What kind of debugger
do you have. Is it a source level debugger? That alone would be
reason enough to do the work on the VAX.
regards,
steve mcafee
|
| 659.8 | Don't forget the hardware solution! | NAC::VISSER | | Fri Aug 21 1987 14:00 | 12 |
| Why not forget the VAX connection for a moment and reconsider the
need; as I see it, a desire to speed the development process. If
most of the development time is spent compiling and linking, why
not develope a C devel. co-processor? One could build a simple
68000 SBC with an SCSI interface that images the 2nd 68k's ram into
SCSI space. The result would be the remote 68k cranking on your
compile or link, getting include files from your SCSI drive without
Amiga intervention, i.e., SCSI device to device communication
(supported in the ANSI SCSI spec). This SCSI coprocessor could
also be used for other purposes, like ray tracing, etc.
John
|
| 659.9 | Symbolic Debuger | ISTG::WISNER | Paul Wisner | Tue Aug 25 1987 17:13 | 19 |
| re .7
but couldn't you use the Amiga's STDIO header, and link with the
Amiga's object modules?
re .5,.7
The symbolic debugger greatly speeds up development time,
especially with a language like C (or assembly). It's too bad
the Amiga doesn't have anything like that (for C at least).
Another way to speed up Amiga based C compilation is to add
two or four meg of ram and copy all the include files, object modules
and compiler programs to RAM: disk.
|
| 659.10 | Metascope -- not designed for C, but awesome | WHYVAX::KRUGER | | Thu Sep 17 1987 16:29 | 7 |
| While there is no C source debugger that I'm aware of, Metascope
has an AWESOME full screen debugger for Macro that can help quite
a lot. With a little modification and cooperation with Manx, they
could keep track of which statement they are in, etc. It's a really
fabulous product, if you haven't seen it.
dov
|