Apollo Maggie 3D Chip - Preview Demo

[dreadnought]

[Promilus]

You have to understand that everything becomes asm one day or another, be it by hand or by compilation. So, by definition, everything is doable in asm

No, it becomes machine language. Assembler is something made to work on something more readable than machine language (and with preprocessor symbols, macros etc) but still close enough. C compiler doesn't translate to asm and then ML. It does directly to ML (but you CAN generate asm listing from OUTPUT file).

[meynaf]

Originally Posted by Promilus

No, it becomes machine language. Assembler is something made to work on something more readable than machine language (and with preprocessor symbols, macros etc) but still close enough. C compiler doesn't translate to asm and then ML. It does directly to ML (but you CAN generate asm listing from OUTPUT file).

While it is possible some C compilers generate ML directly, i severely doubt this. Most of them translate to asm or at least it's certainly quite a few of them. As an example, vbcc uses vasm. And, i think, gcc uses as. And it's easier anyway, as peephole asm optimizations are then given "for free".
But it is pretty much unimportant anyway - as a working asm source can be obtained back from ML.

[Promilus]

afaik there's intermediate representation involved which IS NOT asm and while some compilers indeed use asm at the end process (gcc) not all of them (iirc msvc does not, I'm not sure about llvm, probably depends on target...)

[Gorf]

Originally Posted by meynaf

A database based application in asm, what exactly would make it so difficult ?
It does not look very complicated.

Hmm
How about this one:
https://couchdb.apache.org
https://github.com/apache/couchdb

Well defined stable feature set. Stable API for years.
No GUI, no real dependencies on the OS.

The current implementation in based on Erlang and the BEAM VM.

How long would it take you to make a handwritten fully funktional clone in 68K ASM?

(If it would exist, I would use it.)

[Bren McGuire]

lol its 2022, amiga enters the world of deprecated 3D with no apps to support it... no thanks

[meynaf]

Originally Posted by Gorf

How long would it take you to make a handwritten fully funktional clone in 68K ASM?

Like with any other language, many months of work i suppose (of which most of the time would be spent attempting to understand original code).
But as i said earlier, i don't work for free on projects that don't interest me.

Wait.
If other languages are so good, how come nobody did that already with one of them ?
With what has this program been made already ? Why don't we have this language available for our miggies ?

[Gorf]

Originally Posted by meynaf

Like with any other language, many months of work i suppose (of which most of the time would be spent attempting to understand original code).

I guess that would not be overly helpful in this case since it is in erlang.
A complete fresh start from the API definitions would probably make much more sense.

But as i said earlier, i don't work for free on projects that don't interest me.

So we can never find out, if your claims are true.

Wait.
If other languages are so good, how come nobody did that already with one of them ?

They did: CouchBase is a reimplementation in C++ and Go.
That said: It's not that erlang is somehow bad or needs to be replaced in the first place other than many coders are not familiar with it.

Still nobody tried to do it in ASM.
Why?

With what has this program been made already ?

https://www.erlang.org

The native file format even uses IFF:
https://www.erlang.org/doc/man/beam_lib.html

Why don't we have this language available for our miggies ?

Because nobody ported it.

A port of BEAM VM and erlang in 68k assembler would also be nice.

[meynaf]

Originally Posted by Gorf

I guess that would not be overly helpful in this case since it is in erlang.
A complete fresh start from the API definitions would probably make much more sense.

Not sure if the mere API definitions are enough, haven't seen them.
Sometimes these things are unclear and unsuitable for a full reimplementation.
The biggest part for such a project isn't actual implementation, it's all about knowing what exactly is to be done...

Originally Posted by Gorf

So we can never find out, if your claims are true.

Even if i did it, you (and/or the others here) wouldn't admit you're (or they're) wrong.
So that's quite a lot of work for basically nothing.

Why not starting with something simpler ?
With which size do "HLL advantages" are supposed to start to show up ? If HLLs are so good, even for moderate-sized projects it should show ? Maybe even for small ones ?
Fancy a coding contest then ?

Originally Posted by Gorf

They did: CouchBase is a reimplementation in C++ and Go.
That said: It's not that erlang is somehow bad or needs to be replaced in the first place other than many coders are not familiar with it.

Then take that part in Go, rewrite it in C/C++, and you're done.
Or maybe these languages are finally not that portable after all ?

Originally Posted by Gorf

Still nobody tried to do it in ASM.
Why?

Because nobody cared about the Amiga.
Or, "Because nobody ported it."

Originally Posted by Gorf

Because nobody ported it.

Why ? HLLs are supposed to be portable aren't they ?

Originally Posted by Gorf

A port of BEAM VM and erlang in 68k assembler would also be nice.

Quite a lot of things would be nice.
Now why does not a C lover from here port that with C ? Shouldn't it be a lot easier ?

[Bren McGuire]

jesus f christ

[Gorf]

Originally Posted by meynaf

Not sure if the mere API definitions are enough, haven't seen them.
Sometimes these things are unclear and unsuitable for a full reimplementation.
The biggest part for such a project isn't actual implementation, it's all about knowing what exactly is to be done...

this should not be the case for CouchDB - the documentation makes really clear what it does. It only communicates via REST and JSON, which are also well defined:
https://en.wikipedia.org/wiki/Repres...state_transfer
https://en.wikipedia.org/wiki/JSON

Even if i did it, you (and/or the others here) wouldn't admit you're (or they're) wrong.
So that's quite a lot of work for basically nothing.

You can prove the others wrong.
I never said you can not do it, just that there is no evidence, so we can not know. If there is evidence I am happy to acknowledge that.

Why not starting with something simpler ?

Because that is the whole point.
Just some isolated routines or algorithms do not prove your claims.

With which size do "HLL advantages" are supposed to start to show up? If HLLs are so good, even for moderate-sized projects it should show ? Maybe even for small ones?

It does show:
99% of projects outside of Amiga-land are done in some HLL.
Probably because a goal is much easier and faster to archive this way.

You say these are all bloat. Maybe.
But still virtually nobody wants to do these things in assembler. Even in time-critical fields with very few exceptions. Even in scientific High Performance Computing where processor-time still matters almost nobody is using assembler.

And that is not just because x86(_64), POWER or ARM assembly is not that nice:
One could use a nice orthogonal 68K or NS32000 like "language" instead... but virtually nobody does.

My interpretation from my own experience is, that it is just to tedious and rough to do so.
It would cost me so much more time to reach my goal, or I would probably not even get there ...

That might be different for you - but there is still no proof of that.

Fancy a coding contest then ?

I already know, that I am not a good programmer.
But it is still good enough to earn my living with it, but only because I take the easy (smart?) road.

I use said CouchDB in my projects and it works.
A smaller faster version in handcrafted ASM would be nice, but I certainly would not be able to do that in many years - if at all!
But I need to use it now, so I use what is there.

And I use other bloatware like node.js and JS to build my projects that use this DB on the server-side ... and other bloated tools to write the client-side.

It is stable, it scales almost indefinitely, it runs in parallel, and I can easily make adjustments and reuse my code ... and not only I can do that but also others working on that project.
I could not do that in ASM, no matter what ISA.

Then take that part in Go, rewrite it in C/C++, and you're done.
Or maybe these languages are finally not that portable after all ?

How would that give me handcrafted 68K assembler?

Because nobody cared about the Amiga.
Or, "Because nobody ported it."

Nobody ported it to or rewrote it in ASM. That is the point here.
Older versions of erlang do run on the Amiga on 68k Debian.

Why ? HLLs are supposed to be portable aren't they ?

A language needs an interpreter/compiler and that is just a program.
And they are (in general) not more portable than other programs.

The advantage is not that the HLL itself is portable, but that other programs written in that language can be recompiled on various systems and platforms once a compiler for these platforms exist.
The complete Linux user-land and 99% of the kernel are written in a HLL ... and guess what: it runs (natively!) almost everywhere on almost everything (including Amigas).

Whereas 68k-Assembly coded Amiga programs run only on Amiga unless you emulate the whole hardware on an other machine.

Quite a lot of things would be nice.
Now why does not a C lover from here port that with C ? Shouldn't it be a lot easier ?

Because you are moving the goalpost again.
It was not about porting things written in a HLL to other hardware or systems, but about the question if it is really doable in handcrafted ASM.

[meynaf]

Originally Posted by Gorf

this should not be the case for CouchDB - the documentation makes really clear what it does. It only communicates via REST and JSON, which are also well defined:
https://en.wikipedia.org/wiki/Repres...state_transfer
https://en.wikipedia.org/wiki/JSON

By looking at that, i start to wonder : where's the sense in that ? I mean, where's the point in doing all this, what exactly do they want to achieve when doing all this ?
For me it looks like a typical case of "making a mountain out of a molehill" (or "using a tank to go shopping", at your choice).

Originally Posted by Gorf

You can prove the others wrong.
I never said you can not do it, just that there is no evidence, so we can not know. If there is evidence I am happy to acknowledge that.

As for yourself maybe, but some others here wouldn't change their mind even when facing a proof.

Originally Posted by Gorf

Because that is the whole point.
Just some isolated routines or algorithms do not prove your claims.

So what is the minimum acceptable size ?

Originally Posted by Gorf

It does show:
99% of projects outside of Amiga-land are done in some HLL.
Probably because a goal is much easier and faster to archive this way.

You say there are all bloat. Maybe.
But still virtually nobody wants to do these things in assembler. Even in time-critical fields with very few exceptions. Even in scientific High Performance Computing where processor-time still matters almost nobody is using assembler.

And that is not just because x86(_64), POWER or ARM Assembly is not that nice:
One could use a nice orthogonal 68K or NS32000 like "language" instead... but virtually nobody does.

My interpretation from my own experience is, that it is just to tedious and rough to do so.
It would cost my so much more time to reach my goal, or I would probably not even get there ...

That might be different for you - but there is still no proof of that.

Well, it's possible to do whole OS in x86 asm.

Originally Posted by Gorf

I already know, that I am not a good programmer.
But it is still good enough to earn my living with it, but only because I take the easy (smart?) road.

I use said CouchDB in my projects and it works.
A smaller faster version in handcrafted ASM would be nice, but I would not be able to do that in many years - if at all!
But I need to use it now, so I use what is there.

And I use other bloatware like node.js and JS to build my projects that use this DB on the server-side ... and other bloated tools to write the client-side.

It is stable, it scales almost indefinitely, it runs in parallel, and I can easily make adjustments and reuse my code ... and not only I can do that but also others working on that project.
I could not don that in ASM, no matter what ISA.

I don't think I can prove my point without someone else doing same work on the other side.

Originally Posted by Gorf

How would that give me handcrafted 68K assembler?

Why do you want that ? Don't you just want a program that works ?

Originally Posted by Gorf

Nobody ported it to or rewrote it in ASM. That is the point here.
Older versions of erlang do run on the Amiga on 68k Debian.

Perhaps there is simply no point in porting this. What would we use it for anyway if we had it ?

Originally Posted by Gorf

Whereas 68k-Assembly coded Amiga programs run only on Amiga unless you emulate the whole hardware on an other machine.

Not true for my own programs ; i could just port my system framework to another 68k machine (like Atari) and they would work after simply reassembling them.
Besides, an ahead-of-time compiler isn't that different from a static compiler used for HLLs, so one could treat 68k-asm exactly like if it were just another language to be compiled.

Originally Posted by Gorf

Because you are moving the goalpost again.
It was not about porting things written in a HLL to other hardware or systems, but about the question if it is really doable in handcrafted ASM.

Then you don't really need these programs, you just want me to work for free.

The thing is, i will not write an enormous program just to prove people here that they are wrong.
Actually anything i could do wouldn't be accepted as a valid proof, knowing how stubborn some folks can be.
I could tell yourself that i can handle a one-megabyte executable for a whole game in pure asm just fine and you would find an excuse to not accept this as a proof (not complicated enough ? too small ?).

[Promilus]

Well, it's possible to do whole OS in x86 asm.

It only took more than a decade Yeah, I know, working version was done long ago but progress during that decade shows how complex hobbyist project in asm isn't easy and fast to develop.

[meynaf]

Originally Posted by Promilus

It only took more than a decade

And how long did it take for the mainstream OSes we have today ?

[Bruce Abbott]

Originally Posted by Bren McGuire

lol its 2022, amiga enters the world of deprecated 3D with no apps to support it... no thanks

lol it's 2022, and we enter a world where...

- Over 3,000 people per day are dying in the UK alone, from virus that was preventable with modern technology but we were too dumb to use it.

- Russia is attacking a democratic European country to eliminate 'drug-taking Nazis'.

- A global microchip shortage shortage is seriously curtailing the production of many products, including motor vehicles.

- The biggest application for graphics chips is making fake money.

- Online trolls are even invading retro computing forums where people are just trying to forget about the ills of the modern world and have fun like we used to in the 90's.

[Bruce Abbott]

Originally Posted by Thomas Richter

So let's look at this: What does the "27 times faster assembling" buy you? Next to nothing.

What does 27 times get me? The difference between an assembly time of 3 seconds and 1.5 minutes. You might call that 'next to nothing' - I call it the difference between enjoying myself and getting frustrated.

But let's look at the product: "ProAsm", last Aminet release 1997. Vasm - last release... I don't know, probably this year?

The modern programming paradigm in a nutshell - Who cares about efficiency, the most import thing is how often you push out updates.

This has to be the worst argument ever. Imagine you bought a car in 1997 (same year I purchased a license for ProAsm) and today were told you should discard it for this new vehicle which has a top speed of 5kph. Would you take that advice?

Now, that tells you a lecture more than the speed. Asm source is "outdated, unmaintained".

Another bad argument. This has nothing to do with asm being "outdated, unmaintained". If Daniel Weber had released the source code for ProAsm then updating it would have been a doddle.

The same problem applies to many other programs produced for the Amiga and other platforms. People today are going to great lengths to decompile or rewrite from scratch code for classic games etc. on the PC too. Games like Doom and Quake get ported to the Amiga not necessarily because we want to play those games specifically, but simply because we have the source code for them.

High-level language source may be less efficient, but closer to the actual problem you want to solve.

The 'problem' I want to 'solve' is how to enjoy what time I have left in this world, and having a fast assembler is a big part of that.

In 1991 I bought an A3000 at great expense primarily to cut down assembly time on the commercial project I was working on. As you know, time is money. With a faster machine I could be more productive. Funny thing is, shortly after buying the A3000 I discovered Devpac, which was 5 times faster than my previous assembler. The A3000 was 5 times faster than my A1000, so I could have avoided the expense of a new computer simply by upgrading to a more efficient assembler!

Will you update ProAsm? I doubt it. It's not worth the investment of time.

I already have. I only have one more update to do and it will be perfect. The only 'problem' is I first have to understand exactly how the code works so I don't make a mess of it.

That is *exactly* the problem with assembler code.

It's the problem with any source code that isn't available, even for modern stuff. Rewriting complex software from scratch is a waste of resources, but it's often the only option due to licensing restrictions or because the original code has been lost. At least with asm you can disassemble the machine code to get readable source that is close to the original, which may be enough to change it without too much effort.

[Gorf]

Originally Posted by meynaf

By looking at that, i start to wonder : where's the sense in that ? I mean, where's the point in doing all this, what exactly do they want to achieve when doing all this ?
For me it looks like a typical case of "making a mountain out of a molehill" (or "using a tank to go shopping", at your choice).

You seem not to understand what it does or what services use distributed NoSQL databases...
For this particular one, which I also use for my project, there are many other examples:

Users of CouchDB include:

• CERN uses CouchDB as database for the Data Management System at the Large Hadron Collider.
• Red Cross use the application iDAT for electronically casework in disaster areas. Here CouchDB is used as multi-node peer-to-peer offline-first database for iDAT.
• IBM Cloud services are based at a fundamental level on CouchDB.
• United Airlines uses CouchDB for the in-flight entertainment systems in over 3,000 planes.
• Credit Suisse, for internal use at commodities department for their marketplace framework.
• BBC, for a dynamic CMS-Platform.
• CANAL+ for international on-demand platform at CANAL+ Overseas.
• ...

(Wikipedia)

Well, good that it is only a molehill:

So what is the minimum acceptable size?

Molehill sized is enough.

Well, it's possible to do whole OS in x86 asm.

I remember testing this many years ago, when it had no applications.
It fits on a singe floppy (so does AmigaOS), but you couldn't do anything with it...
It was at this time far less impressive than the QNX floppy ...

Later someone ported some C libraries and POSIX stuff to make Doom running ... all not in assembler.

Now many years later it seams there are a couple of small programs available ...

Still a great achievement, but on a very slow development path - because of ASM?

Will you port it to the Amiga-hardware?

I don't think I can prove my point without someone else doing same work on the other side.

Because I am lazy, I suggested things that are already implemented in HLL.
So the work on the other side is already done.
You can prove your point, by making a better version in handcrafted ASM.
As you prefer 68K, that would be fine.

Why do you want that ? Don't you just want a program that works ?

Of course I would prefer a faster version with less bloat and smaller memory footprint.
Your claim was, you could do that with any large program written in HLL by reimplementing it in ASM.

Perhaps there is simply no point in porting this. What would we use it for anyway if we had it ?

Besides CouchDB obviously?

E.g:
ejabberd (XMPP server (Jabber server), MQTT broker and SIP gateway)
Wings 3D (polygon modeller)

and of course a second language "Elixir" that uses the Erlang VM
https://elixir-lang.org

Which in turn brings us things like:

Phoenix (web application constructor/framework)
Bamboo (mailserver)
Kalevala (world building toolkit for text based games)
Ratatouille (declarative terminal UI kit)
Toby (Terminal for Ratatouille)
Loki, ExCLI (toolkit for building command-line interfaces)
Numerix (statistics, linear algebra, machine learning ...)

Not true for my own programs ; i could just port my system framework to another 68k machine (like Atari) and they would work after simply reassembling them.

68k-Macs as well?
(Not that secret frameworks are helpful for the rest of us...)

Besides, an ahead-of-time compiler isn't that different from a static compiler used for HLLs, so one could treat 68k-asm exactly like if it were just another language to be compiled.

But nobody does ...

Then you don't really need these programs, you just want me to work for free.

I never said I would need them. I said it would be nice.
It was simply chance to prove your claims.

The thing is, i will not write an enormous program just to prove people here that they are wrong.

So we can never be sure.

Actually anything i could do wouldn't be accepted as a valid proof, knowing how stubborn some folks can be.
I could tell yourself that i can handle a one-megabyte executable for a whole game in pure asm just fine and you would find an excuse to not accept this as a proof (not complicated enough ? too small ?).

As you said yourself earlier: we need something to compare it against.
Some version of the same thing, done in HLL.

[Gorf]

Originally Posted by Bruce Abbott

What does 27 times get me? The difference between an assembly time of 3 seconds and 1.5 minutes. You might call that 'next to nothing' - I call it the difference between enjoying myself and getting frustrated.

OK.
So far so understandable.
But:

In 1991 I bought an A3000 at great expense primarily to cut down assembly time on the commercial project I was working on. As you know, time is money. With a faster machine I could be more productive. Funny thing is, shortly after buying the A3000 I discovered Devpac, which was 5 times faster than my previous assembler. The A3000 was 5 times faster than my A1000, so I could have avoided the expense of a new computer simply by upgrading to a more efficient assembler!

Your A3000 was still (at least) 5x faster - so in combination with Devpac it was total speedup of 25x compared to your old setup.

Not getting both in the end would lead to frustration, wouldn't it?

[meynaf]

Originally Posted by Gorf

You seem not to understand what it does or what services use distributed NoSQL databases...
For this particular one, which I also use for my project, there are many other examples:

Users of CouchDB include:

• CERN uses CouchDB as database for the Data Management System at the Large Hadron Collider.
• Red Cross use the application iDAT for electronically casework in disaster areas. Here CouchDB is used as multi-node peer-to-peer offline-first database for iDAT.
• IBM Cloud services are based at a fundamental level on CouchDB.
• United Airlines uses CouchDB for the in-flight entertainment systems in over 3,000 planes.
• Credit Suisse, for internal use at commodities department for their marketplace framework.
• BBC, for a dynamic CMS-Platform.
• CANAL+ for international on-demand platform at CANAL+ Overseas.
• ...

(Wikipedia)

Well, good that it is only a molehill:

None of these are anything we'd want to do on our Amigas, in case you have not noticed.

Originally Posted by Gorf

Molehill sized is enough.

Which amounts to ?

Originally Posted by Gorf

I remember testing this many years ago, when it had no applications.
It fits on a singe floppy (so does AmigaOS), but you couldn't do anything with it...
It was at this time far less impressive than the QNX floppy ...

Later someone ported some C libraries and POSIX stuff to make Doom running ... all not in assembler.

Now many years later it seams there are a couple of small programs available ...

Still a great achievement, but on a very slow development path - because of ASM?

I didn't follow the project, but yes, maybe it was slow dev because of ASM.
But may I recall you the terrible truth ? It is x86 asm !

Originally Posted by Gorf

Will you port it to the Amiga-hardware?

Where's the point in doing that ? We already have a lean-and-mean OS !

Originally Posted by Gorf

Because I am lazy, I suggested things that are already implemented in HLL.
So the work on the other side is already done there.
You can prove your point, by making a better version in handcrafted ASM.
As you prefer 68K, that would be fine.

As you are lazy, you can understand I may be lazy as well.
Thus i'd prefer having someone implement in HLL something that's already done in handcrafted ASM

Originally Posted by Gorf

Of course I would prefer a faster version with less bloat and smaller memory footprint.
Your claim was, you could do that with any large programs written in HLL by reimplementing it in ASM.

Well, while i could do it if i really wanted to, i'm still not at the command of anyone so i do the projects I want.

Originally Posted by Gorf

Besides CouchDB obviously?

E.g:
ejabberd (XMPP server (Jabber server), MQTT broker and SIP gateway)
Wings 3D (polygon modeller)

and of course a second language "Elixir" that uses the Erlang VM
https://elixir-lang.org

Which in turn brings us things like:

Phoenix (web application constructor/framework)
Bamboo (mailserver)
Kalevala (world building toolkit for text based games)
Ratatouille (declarative terminal UI kit)
Toby (Terminal for Ratatouille)
Loki, ExCLI (toolkit for building command-line interfaces)
Numerix (statistics, linear algebra, machine learning ...)

Nah, frankly, do you really want to have all these on the Amiga ?

Originally Posted by Gorf

68k-Macs as well?

Yes, 68k Macs as well.

Originally Posted by Gorf

(Not that secret framework are helpful for the rest of us...)

It's not "secret", a few people got some version of it. It starts by just asking.

Originally Posted by Gorf

But nobody does ...

How did Apple handle compatibility with 68k code when they switched to PPC already ?

Originally Posted by Gorf

I never said I would need them. I said it would be nice.
It was simply change to prove your claims.

Sorry, i've got enough "nice" things to do.
Why should i prove anything, anyhow ?

Originally Posted by Gorf

So we can never be sure.

This is the way life is.

Originally Posted by Gorf

As you said yourself earlier: we need something to compare it against.
Some version of the same thing, done in HLL.

Like a player for some audio format, for example ?
You (or anyone) could attempt to beat my 030-optimized version of mpega.library with HLL
(Or do any other format with similar cpu power requirements.)
Or perhaps decode and show a jpeg image on regular AGA machine ? Or PNG maybe ?
Fast HAM8 renderer must be real fun to do in C

[Thomas Richter]

Originally Posted by meynaf

While it is possible some C compilers generate ML directly, i severely doubt this. Most of them translate to asm or at least it's certainly quite a few of them.

Err. No. You have no idea how compilers work, and they don't work like this. Compilers create an abstract syntax representation from the input, then optimize on this abstract description.



Ever wonder what the "quad" files are the Lattice C compiler generates (and the SAS/C compiler still holds internally)? This is exactly the internal representation. It is not assembler. It is an abstract description on the program flow and the objects that are manipulated.


Only the very last part of the compiler creates object code from this abstract description, the "code generator".


So, for example, here is how SAS/C works:


"sc1" is the preprocessor and parser. Its output is the abstract description of the code, the "quad" file.


"scgo" is the "global optimizer", it optimizes beteween functoins, on the "quad" file.


"sc2" is the final code generator from the quad file.


There is no assembler at any level, it goes from quad to object code. You get an assembler as part of the package ("asm"), and even an object code disassembler ("omd"), but that's not run as part of the compilation process. You can check with SnoopDos if you want.

Originally Posted by meynaf

As an example, vbcc uses vasm. And, i think, gcc uses as.

No, it doesn't. The gcc package comes with an assembler, "gas", but it is not required for the compiler chain. It uses a similar workflow as SAS/C, but quite a bit more sophisticated over multiple representations of the code.

Originally Posted by meynaf

And it's easier anyway, as peephole asm optimizations are then given "for free".

"Peephole optimization" is not a text-parsing exercise. It is the very last stage after instructions have been selected, and then another step is run on this representation. But it would be wasteful to represent the instructions in assembler mnemonics.



[/QUOTE]

But it is pretty much unimportant anyway - as a working asm source can be obtained back from ML.[/QUOTE]
Not quite, as with just having object code, you still do not know what is code and what is data, or whether it is even both.