bissiri@blake.acs.washington.edu (Moja Fritzah) (05/02/89)
Does anybody care to respond: WHat is your favourite assembler, and why? -kevin
bissiri@blake.acs.washington.edu (Moja Fritzah) (05/03/89)
Someone on the net recommended Assempro as the assembler of choice. THis person said that the program is a GEM program. DOes it also support a command line interpreter? ANy complaints/raves about Assempro? Other assemblers preferred? Thanks for the help. -kevin
usenet@TSfR.UUCP (usenet) (05/03/89)
In article <1837@blake.acs.washington.edu> bissiri@blake.acs.washington.edu (Moja Fritzah) writes: >Does anybody care to respond: WHat is your favourite assembler, and why? Alcyon. It's moderately quick on the my handmade assembly, I trust it more than Sozobon jas, and it backends the Alcyon C compiler. I've not used any other assemblers for the ST (MadMac scared me off by warning me that it would not generate code that was as good as the Alcyon assember - and I'm _very_ keen on compact binaries.) If you include other machines, then Macro-11 is what God himself intended an assembler to be.... -david parsons -orc@pell.uucp
cs163afu@sdcc10.ucsd.EDU (Some call me...Tim) (05/04/89)
In article <1837@blake.acs.washington.edu> bissiri@blake.acs.washington.edu (Moja Fritzah) writes: >Does anybody care to respond: WHat is your favourite assembler, and why? MadMac in the Atari Developer's kit, for one reason: Speed. I've seen MadMac assemble three files, link them, and run them from a hard disk in about three seconds. It's code isn't "optimized." What this means is that branches don't get cut to short branches. Therefore each branch you use takes up 4 bytes instead of two. EXCEPT, of course, if you include an extension (bra.s or bra.b), in which case the branch is forced to short. And if you really want it optimized--after you have it running, use the Alcyon assembler at that point. They are completely code compatible. ------------ Tim Mensch Internet: tmensch@ucsd.edu
apratt@atari.UUCP (Allan Pratt) (05/05/89)
In article <99@sdcc10.ucsd.EDU> cs163afu@sdcc10.ucsd.edu.UUCP (Some call me...Tim) writes: > MadMac in the Atari Developer's kit, for one reason: Speed. You betcha. > And if you really want it optimized--after you have it running, use > the Alcyon assembler at that point. They are completely code > compatible. They are NOT completely compatible. It is possible to write code which assembles the same (modulo optimizations) under both assemblers. However, MadMac is more strict on some points (colon after label, semicolon before comment) and AS68 doesn't have macros. Furthermore, the syntax for conditional assembly is totally different, and the behavior of "=" and "set" and "equ" might be different. MadMac has an option (-6) which lets you assemble Alcyon compiler output. It is NOT an AS68 compatibility mode; it is a C68 back-end mode. It simply ignores lines beginning with "~" and does some other things (I forget what). You can ask MadMac to inform you of unoptimized short branches, so you can go back and put ".s" on them. AS68 doesn't know about the XXXX.w addressing mode: INPUT MadMac output AS68 output ------------ ------------------------ -------------------------- lea $1234,a0 lea $1234.w,a0 (2 words) lea $00001234,a0 (3 words) Lastly, AS68 makes at least one illegal optimization. Assuming that a missing size modifier means the same as .w, the optimization move #1,d0 --> moveq.l #1,d0 which AS68 does is illegal. MadMac does moveq, addq, and subq optimization correctly. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
bissiri@blake.acs.washington.edu (Moja Fritzah) (05/06/89)
A global thanks to the netters who
responded to my "What assembler do you use..?" inquiry.
Since I am about to purchase an assembler,
I wanted to find out what the pros are using
and why they prefer one assembler over another.
Here are some of the choices with a quote or two as reason(s):
ASSEMBLER VOTES REASONS
MadMac 3 "Speed"; "...supports command line.."; "macros"
AssemPro 1.5 "Completely GEM, good optimizer, debugger.."
MWC 1 "..[assembler understands peculiarities of comp.].."
GAS 1 "..option to add C++ with their GC++ package..."
Alcyon 1 "Moderately quick...trust it...backends Alcyon C.."
Macro-11 1 "..other machines... God's idea of an assembler..."
Since I can't imagine working without GULAM, i am sure i will
go with a non-GEM interface. Considering that MWC is not a
full assembler, and that GAS and GCC prefer a machine
with more than 1 meg, I am left with Alcyon and MadMac. Can't imagine
coding without power of macros... leaves me with MadMac... and possibly
for the most important reasons: Speed and flexibility.
Does this decision put me in the position of purchasing the Developer's Kit?
(i've been wanting to register anyway)
Thanks for all the help!
-kevin
P.S. Anbody else care to append this list..?dbrooks@osf.OSF.ORG (David Brooks) (05/08/89)
In article <1480@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: [...] >Lastly, AS68 makes at least one illegal optimization. Assuming that a >missing size modifier means the same as .w, the optimization > > move #1,d0 --> moveq.l #1,d0 > >which AS68 does is illegal. MadMac does moveq, addq, and subq >optimization correctly. I'd always thought of the <opcode-without-qualifier> as "Here, assembler, I don't care about the most significant three bytes; you do whatever's best". (hacker's note: moveq.l is faster than the other forms of move-literal; it sign-extends one byte across the whole long). If I *do* care, I get specific. -- David Brooks dbrooks@osf.org Open Software Foundation uunet!osf.org!dbrooks 11 Cambridge Center Personal views, not necessarily those Cambridge, MA 02142, USA of OSF, its sponsors or members.
dac@ukc.ac.uk (David Clear) (05/08/89)
In reply to the person who was asking about assemblers, I use DevpacST version 2. It allows assembly into memory and testing without leaving the system. The optimizer isn't that hot but apart from that it's very good. The debugger is very impressive. It has been used to write quite a few games (if games aren't your scene, then don't worry - AES/GEM/VDI macros and other routines are included). Well, that's my bit. -- % cc life.c | David Clear <dac@ukc.ac.uk> % a.out | Computer Science, University of Kent, Segmentation fault (core dumped) | Canterbury, England.
landon@Apple.COM (Landon Dyer) (05/09/89)
In article <1480@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >Lastly, AS68 makes at least one illegal optimization. Assuming that a >missing size modifier means the same as .w, the optimization > > move #1,d0 --> moveq.l #1,d0 > >which AS68 does is illegal. MadMac does moveq, addq, and subq >optimization correctly. Not true (unless you've fixed it recently, Allan). Take a look at the Bios and XBios macros in "atari.s" -- they have some pretty icky conditional assembly to optimize an ADD #n,SP to an ADDQ #n,SP. Mistakes Were Made. But [get closer to the campfire, kids -- this is scary] AS68 "optimizes" MOVE.W #0,D0 (note the explicit .W) to MOVEQ #0,D0. WUPS! Erring on the side of caution is not always a bad thing... -- Landon Dyer, Apple Computer, Inc. Development Systems Group (MPW) Everything I said here is utter nonsense. Give a little bit.
stefan@spcc386.UUCP (Stefan Posthuma) (05/09/89)
My favourite assembler? DevPack 2.0 of course (in my opinion the only decent one). It's fast, it's easy to use and it has a very extensive debugger. Assembly is two-pass and very quick if you assemble into memory. After that, you can execute it from memory or debug it with full options like trace, labels, multiple windows (no GEM windows) etc. Also, it has full macro and conditional assembly handling and a complete GEM-call library. It can create GST format object files or its own format. I mainly use it to create demo screens and no matter how I fool around in the memory of the ST and no matter how many interrupt vectors I screw up and no matter how many screen borders I obliterate, it still works fine. If you are thinking about assembly on the ST, DevPack is perfect.