acmfiu@serss0.fiu.edu (ACMFIU) (05/23/91)
the orca/m v merlin debate will go on forever. however, i'd advise you to get merlin, even if you choose to link in HLL. the downside to merlin are two things: 1. pathetic interface (but good editor) 2. must run separately apart from this, i think merlin rules. orca/m's macro capability is superb. this truly makes it stand out. however, i find all the macros i need to be in merlin (and the only ones i use are the _tool toolbox macros). tim meekins has created an impressive library of macros for orca/m which truly show off it's power. however, there are basically two things i can't stand about orca/m 1. way way too slow. 2. it doesn't have :local labels. the following is orca/m code: foo start bra loop2 oof bra loop3 bra loop4 end the following is the same in merlin code: foo equ * bra :1 oof bra :2 bra :1 now the difference here is you can reuse :<var> variables in the context of an enclosing <variable> without the ':'. this is unbelievably useful. this is probably *the* reason i bought merlin. shows you how picky i am, huh. albert
MQUINN@UTCVM.BITNET (05/24/91)
On Thu, 23 May 91 00:49:47 GMT ACMFIU said: [talking about Merlin assembler vs. ORCA/M] >however, there are basically two things i can't stand about orca/m > 1. way way too slow. Soooo true. > 2. it doesn't have :local labels. This isn't necessarily true. You -can- have local variables with ORCA/M. Just use different code segments. All labels inside a code segment are local to that segment, unless defined globally, with the GEQU directive. Although, this is not as powerful as the kind of locals you're talking about, it does support locals. >albert ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com
rhyde@koufax.ucr.edu (randy hyde) (05/25/91)
>>> local labels in Merlin vs. ORCA
LISA has better local labels that either assembler. And LISA is free.edwatkeys@pro-sol.cts.com (Ed Watkeys) (05/25/91)
In-Reply-To: message from MQUINN@UTCVM.BITNET It was said that ORCA/M locals aren't as "good" as Merlin ones, and I think that's dead wrong. While ORCA/M is slower (by far) than Merlin, if you turn off the display and don't use the libraries, things speed up considerably. And, if you have 128K, you can put your source and macro files in /RAM. This makes things about even (not strictly, but it's good enough that it isn't way way too slow). Before I say what I'm about to say, just let me say that I started with Merlin in '84 or something, got a DOS 3.3 version of ORCA/M for $10 at a compuuter show and then bought 4.1 through Bytes Works (along with Small-C and the source code to the libraries). Just recently, I switched back to Merlin, mostly because I had the money to buy it and I wanted to write some Davex external commands (Dave provides Merlin PUT files, but no ORCA ones...). The following is my feelings about using two generations of both ORCA/M and Merlin... For quick and dirty stuff, Merlin is by far easier to use. The way it is implemented (the menu, etc...) leaves a lot to be desired, I think. I prefer commands lines to menus, and Ilike being able to use the delete key on my IIc (nitpicking, yes...) Also, testing programs from withing Merlin is a pain, since everything is in memory, and ProDOS acts strange. Overall, it seems to be a port of a DOS 3.3 program (which is what it is). ORCA/M is better for large jobs in my estimation. There are a huge number of pseudo-ops which can do almost anything that you'd want to do. Also, it includes a large macro and subroutine library which can be invaluable. The START...END and DATA...END are superior to Merlin's local variables, which seem like a hack to me. ORCA/M can produce LINKED files limited only by disk space, allows integration of other languages, and provides a command shell that does far more than Merlin's disk commands. One thing in Merlin's favor is that you can have multiple DSKs in a file. This means that you can reference program modules external to the current one, which makes overlays far easier. What I mean to say above is that you have access to ALL global variables in a source file, regardless of where those labels end up in terms of BIN files. The only way this can be done in ORCA/M is through jump tables or some other workaround. This strength is a plus for big application development, but I still think ORCA/M is better for the huge things... For me, it comes down to this: If I'm going to have to know what I writing means in six months, I'll use ORCA/M; but if I'm working on it for three days straight and will never have to look at it again, I'll use Merlin. Ed Ed Watkeys III Internet: edwatkeys@pro-sol.cts.com ProLine: edwatkeys@pro-sol UUCP: crash!pro-sol!edwatkeys ARPA: crash!pro-sol!edwatkeys@nosc.mil BitNET: edwatkeys%pro-sol.cts.com@nosc.mil
shrinkit@Apple.COM (Andrew Nicholas) (05/27/91)
In article <14704@ucrmath.ucr.edu> rhyde@koufax.ucr.edu (randy hyde) writes: >LISA has better local labels that either assembler. Why is Lisa's better? I'm just curious as to what makes one local label system better than another one I suppose... :) andy -- Andy Nicholas GEnie & America-Online: shrinkit Apple IIGS System Software CompuServe: 70771,2615 Apple Computer, Inc. InterNET: shrinkit@apple.com
edwatkeys@pro-sol.cts.com (Ed Watkeys) (05/28/91)
In-Reply-To: message from shrinkit@Apple.COM
Well, to answer Andy's question (what makes a better local label system
better)...
Like I said before, I use both ORCA/M and Merlin, and know both of the
local label setups. I think that ORCA/M's is better. I'll tell you why...
Under Merlin's system, local labels are local to all source since the last
"real" label. Like this...
ldy #$00
loop lda ($00),y
beq :done
jsr cout
iny
bne loop
:done rts
duh asc 'Print Me'
:blah asc 'Hello'
Okay, the beg can 'see' :done because it is defined after the most recent
'global'. It can not see :blah, however. To me this is a problem. Hust
say I wanted duh to be seen by all the source, but I wanted :blah local.
In the above example, :blah is not local to the executable stuff above.
With ORCA/M, things are easier...
PUT_CSTR START
LDY #$00
BEQ DONE
JSR COUT
INY
BNE LOOP
DONE RTS
DUH ENTRY
DC C'PRINT ME'
BLAH
^- C'HELLO' SHOULD BE THERE...
END
Anyway, I just think that the ORCA/M source code allows the ML programmer
to convert his/her algorithms to code in a way more faithful to high level
languages. It almost forces programmers to write better code, because it
encourages them to encapsulate everything into a single START...END
segment. My ORCA/M stuff looks like works of art, while my MErlin stuff is
a mess. Like I said before, ORCA/M is good for stuff you have to
*understand* a week or so from now. I know thamy lousy programs in Merlin
are my fault, but ORCA/M gives you tools to control yourself... If you
really want to, you can put everything in one segment, so you can have it
either way.
One plus on Merlin's side, however: all this stuff can get complicated in
ORCA/M, while Merlin is straightforward to use. Merlin's manual isn't that
great for new users (it assumes a lot...), while ORCA/M's goes to great
lengths to tell you EVERYTHING about the system in about three different
ways.
Ed Watkeys III
Internet: edwatkeys@pro-sol.cts.com ProLine: edwatkeys@pro-sol
UUCP: crash!pro-sol!edwatkeys ARPA: crash!pro-sol!edwatkeys@nosc.mil
BitNET: edwatkeys%pro-sol.cts.com@nosc.milacmfiu@serss0.fiu.edu (ACMFIU) (05/29/91)
In article <53368@apple.Apple.COM> shrinkit@Apple.COM (Andrew Nicholas) writes: >In article <14704@ucrmath.ucr.edu> rhyde@koufax.ucr.edu (randy hyde) writes: > >>LISA has better local labels that either assembler. > >Why is Lisa's better? I'm just curious as to what makes one local label >system better than another one I suppose... :) > >andy > >-- >Andy Nicholas GEnie & America-Online: shrinkit >Apple IIGS System Software CompuServe: 70771,2615 >Apple Computer, Inc. InterNET: shrinkit@apple.com well, i'll take merlin v. orca and randy can do lisa v. (orca && merlin). whether or not merlin's local labels are a hack i don't know. but if they are, i'm real glad. how often do asm programmers use loops in a given subroutine? i think the answer is enough to warrant an extra type of label that is local to the preceding global variable. i really don't think merlin's local variables are a hack because of the above reason. if i wrote an assembler i don't know if i would have thought of it but if it was suggested to me i would definitely have included it. i look at code in orca that people write and see 'loop1', 'loop2', 'loop3', etc. all over the place. i don't understand how people can live with that. just think what would happen if high-level languages like Pascal and C just let you use a local variable *once*. you'd be dead in the water. albert
rhyde@hubbell.ucr.edu (randy hyde) (06/01/91)
LISA supports two types of local labels: Symbolic and non-symbolic.
Non-symbolic are *marginally* better than ORCA/Merlins. They take the
form
beq >0 ;Go to next ^0 label
bcs <9 ;Go to previous ^9 label.
There is no restrictions on intervening symbolic labels.
LISA also allows you to declare the scope of a label using LBL and RLS
E.g.,
lcl lbl1, lbl2, lbl3, lbl4
.
.
.
rls lbl1, lbl2
.
.
.
rls lbl3, lbl4
the labels lbl1..lbl4 are local until encountering the rls directive.
Lets you control the scope of the labels within the source code.edwatkeys@pro-sol.cts.com (Ed Watkeys) (06/03/91)
In-Reply-To: message from rhyde@hubbell.ucr.edu In any event, LISA and ORCA/M are in a different class from Merlin... Ed Ed Watkeys III Internet: edwatkeys@pro-sol.cts.com ProLine: edwatkeys@pro-sol UUCP: crash!pro-sol!edwatkeys ARPA: crash!pro-sol!edwatkeys@nosc.mil BitNET: edwatkeys%pro-sol.cts.com@nosc.mil