#Manx or Lattice?
11 messages in this thread
Larry, I can find only one thing to critisize in your reply. Standard
object is indeed STANDARD. It was NOT invented by Lattice, nor did they
write Alink. Both were provided with the original AmigaDOS by Metacomco.
Whether you like them or don't like them doesn't matter, Lattice went with
the standard, Manx didn't. This tirade is only to make the history
accurate, it should NOT be construed as an endorsement of either
compiler/system (Metadigm is clearly prejudiced in this area).
I think we are speaking of two different things. (don't you just love the
inconsistent usage of words in the computer field?)
When I spoke of OBJECT, I was speaking of the intermediate results, before
linking. As such, i see no reason why Manx should have had to produce
intermediate files compatible with any other assembler/compiler, as long as
they provided all the tools to create executable from their compiler. That
they did finally modify the intermedaiate files is to their credit, though
it ceretainly wasn't a necessity. The advantage to their system was, of
course, speed of obtaining end results and size of code.
Please note that my preference in C compilers is from an academic point of
view only, since I feel that the only way C can be madereally good is to
jack it up and drive another language under it. 🙂
Larry,
"I see no reason why Manx should have had to produce intermediate files
compatible with any other assembler/compiler…"
I take exception to this statement. A professional software development
tool (as both Aztex and Lattice are) should provide the capability of
mixing code modules developed by other systems (in other languages). The
only way to provide for that is to have a STANDARD format for object files
and a common linker. Wouldn't you like to be able to incorporate changes
into Aterm (for example) by writing new features in your preferred language
of the month (M2 maybe), and still retain the existing C code where usable?
Without a standard object file format, this is not possible. With it, it
would be (assuming that procedural binding protocols can/could be
determined).
Unfortunately, this situation does not currently exist. If the 'standards'
were firmly established and adhered to, it could. And we'd all be better
off for it.
Yes, I agree that it is very desirable to have object compatibility
across compilers, but at the same time, a package that offers a compiler of
itself, complete, and object compatibility is a 'bonus'.
My main point was that Aztec provided speed and small code size compared
to the deathly rummblings of Lattice, that both 'misfeatures' were now
hstory, and in particular, that both had faults.
Bob… that was supposed to be 'a package that offers a compiler and
assembler that produces executable from source is, in and of itself,
complete.'
Dunno what happened there.
<standing ovation>
Mpf, except the 'standards' in this case aren't very good. Even lattice has
recently departed from their former complete observence of the standard,
allowing separate data hunks to be merged, something which manx always did.
There are many very reasonable things which are not allowed with the
'standard' amiga file formats. Manx allows you to link with 'standard'
object files, but as a manx user primarily, I am very glad they didn't
accept the limitations of the current standard.
In principle, I agree with you, but lets get a good standard first, then
lets get everybody to use it.
Scott,
Agreed. The abilitiy to coalesce hunks is important, as is the ability to
NOT coalesce hunks. Lattice currently supports both. Don't know about Manx
(that was one of my first objections to it, the inability to support scatter
loading). Also, unless they fixed it, Manx didn't allow some of the data
hunks to be marked for loading into Chip ram, it was all or none. That is a
serious limitation, IMHO.
I do think we are approaching this mythical standard, although everyone
and their brother seems to be expanding on it. I do hope that we can bring
this all together so the the tools work well with each other.
..Bob
Manx supports scatter loading, had for a year or more, I guess. Lattice only
partially supports merged data, actually, you can't do
dc.l sym1-sym2
for example, unless both are in the same file/hunk. But I agree, things are
getting better all the time. sdb
As regards
DC.L sym1-sym2 not being able to be used unless both are in
the same file, the ADOS binary file format only supports ONE relocation
address. As best I can figure that one, you would need to relate the two syms
to their load addresses and then subtract them. Since we don't know where
they will be until loaded, and if they are in two different modules and thus
have no guarantee of a fixed relationship to each other, I can't see how the
loader could hope to resolve that statement.
Looks like something you'd need to do in an address register at run time
if you really want the number.
<* Wes *>
No, the (intermediate) object format that Lattice has always used, was
originally defined by Metacompost in prehistory. Lattice made their object
format compatible, and 'alink' was just slow. The object format isn't much
different than our AmigaDOS executable load format, just different hunks.
Also, Lattice has seen it fit to register new object format hunks, to make
some of their improvements possible. Since they are the only game in town
besides Metacompost (and who cares about them, right?) they don't have the
hassles associated with registering your own IFF hunks, for example. Now,
the Metacompost disassembler only recognizes the original subset of
object/executable hunks, even though some new ones were/are produced by
both the Manx linker and Lattice.