[comp.sys.amiga] Ideas for next Arp

U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (11/22/88)

I have an (exellent) idea for the next release of Arp:

Put the functionality of REZ into the RESISIDENT command of ARP.
That would mean that
- I can dispense with a library on my (overcrowded) workbench disk
- Some double coding can be avoided (both arp.library and rezlib.library
  supposedly contain some of the same code)
- Everyone finally starts using ASyncRun() and SyncRun() (assuming they
  also fix the bugs :-).

Since the 'principles of operation' of Rez are contained in its
documentation, it should not be too difficult to duplicate.

Another idea: (or rather a bit more like a request):
                    WHEN DO WE GET THE SOURCE ???
I hardly use *any* programs on my Amiga of which I don't have the
source. There must be a very serious reason to run something before
having taken a look at its source. I am almost (but not quite yet)
going to refuse to use the system software because I don't have
the source. I WANT SOURCE! I *always* want source. One of the
reasons I want source is that I can change the program when it does
not entirely do what I want. (I use modified versions of dme,
dmouse, make, pdc (when testing) etc etc).

When will Commodore supply source ??
If not, I might be force to switch to, ehhhm, lets see, a C-64 or
a pclone or an Atari (all of which have disassembled system code
avalable).

(( Just kidding .... but you get what I mean ?? ))

Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)->
        Olaf.Seibert;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +++ Let me tell you that I disclaim anything you care to name +++
 --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet ---
           Study safely - stop deets     7167 BYTES FREE
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

Yes, 7167 is the number of bytes free on an original PET 2001. (7K - 1)
And I have a ROM disassembly of THAT lying around! I always wanted source!

rap@ardent.UUCP (Rob Peck) (11/24/88)

In article <8811221116.AA23400@jade.berkeley.edu>, U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) writes:
> I have an (exellent) idea for the next release of Arp:
> 
> Put the functionality of REZ into the RESISIDENT command of ARP.
> 
> Since the 'principles of operation' of Rez are contained in its
> documentation, it should not be too difficult to duplicate.

As I understood it from Jim Goodnow [some roman numeral], who wrote REZ,
the primary reason it works is that he recognizes some special sequence
of code that is in the Manx 3.6 (and probably later) distributions.  To
make a REZ-compatible system work for ALL compilers would entail some
cooperation on the part of the compiler writers, or some way of recognizing
for each level of each compiler, which compiler produced the code and
an appropriate way of linking it.  If you take a real good look at the
theory of ops Jim has provided, you'll see that it might not be quite
so easy to adapt it to a program done by "any" compiler.  For example,
(as I recall), if there are program globals, he allocates a separate
area of memory for the globals for each new incantation of the program.
Unless you can properly identify all of the hunks, this becomes a
problem.  Jim's implementation of REZ, though, means that a program
need not be designed to be re-entrant in the first place, because each
new incantation looks like a fresh load of the program.

Rob Peck

BRENNER_%DULRUU51.BITNET@cunyvm.cuny.edu (11/24/88)

In Message-ID: <8811221116.AA23400@jade.berkeley.edu> Olaf Seibert writes:

>When will Commodore supply source ??
I fear never. None was supplied on the C64 and 1541.

>If not, I might be force to switch to, ehhhm, lets see, a C-64 or
>a pclone or an Atari (all of which have disassembled system code
>avalable).
Here in Germany we HAVE disassembled ROM listing of exec, the boot rom
of the A1000, the bootstrap and most resources and devices. Two parts are
available, Part 1 contains Exec, Bootstrap and Boot Rom and part 2 contains
the drivers and resources. Both books have a short introduction to the
structures used by the code. I think there will be no more parts following
because:
1) The books sell badly (I really don't understand that!) and
2) who wants to disassemble BCPL or this huge intuition or graphics libs?
Here's the title:
Dr.Ruprecht: Amiga Kommentiertes ROM Listing, Mediscript Verlag Munchen
The only problem: they are in German :-)

>(( Just kidding .... but you get what I mean ?? ))
Yes I do. Especially dealing with exec (eg. writing device driver)
is far more easier with a rom listing at hand.


  @ @    ----------------------------------------------------------------------
===V===    "This message still Beta testing - don't blame me for bugs!" //
  !^!      -Martin (BRENNER_M@DULRUU51.BITNET)  Uni Ulm/F.R.Germany   \X/AMIGA
  ^ ^    ----------------------------------------------------------------------

U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (11/26/88)

[ sorry, can't quote. I read news on another machine than I post from ]

Rob Peck wrote that Jim Goodnow III's REZ recognizes some special
code sequence in programs that are produced by the Manx compiler.

That seems to be true. As far as I can guess, the following is the case.

1. There may be more than one code hunk. No 'small code' model necessary.
2. A custom LoadSeg() must be used, since all relocations must be
   inspected to see if there is more than one reference to the data
   hunk. That one reference should be the one that sets up the base
   register (so disassembly by REZ of the loaded code is hardly necessary)
3. Since the LoadSeg() is already custom, other things can be
   watched that would make sharing the code impossible. Propably,
   a 'virgin' copy of initialized data should be kept, to copy to
   the data segments of processes.

So, I think that the only thing to do for compiler writers is to
make available a 'small data' mode. And all well-known C compilers
for the Amiga do that just fine. (except for PDC...).

One flaw of the current Rez is that it accuses Arp programs to be
written in BCPL (Yuk!) and Dme to be compiled with Lattice (also
far from the truth...). More useful would be an indication of the
amount of memory that they use.

Something unrelated: Sometimes you see claims like 'This program was
written in Manx C'. If I do see such a notice, I immediately question
the knowledgability of the person in question. There is NO Manx C.
There is C, a programming language defined by Kernighan and Ritchie,
(soon also by an ANSI committee), and a Manx compiler, that accepts
programs written in C. Usually, these people really mean to say:
'This program can be compiled with the Manx C compiler'.
But why don't they say that, then???

Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)->
        Olaf.Seibert;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +++ Let me tell you that I disclaim anything you care to name +++
 --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet ---
           Study safely - stop deets     7167 BYTES FREE
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

lphillips@lpami.van-bc.UUCP (Larry Phillips) (11/27/88)

In <8811251850.AA06178@jade.berkeley.edu>,
    U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) writes:
> .... There is NO Manx C.
> There is C, a programming language defined by Kernighan and Ritchie,
> (soon also by an ANSI committee), and a Manx compiler, that accepts
> programs written in C. Usually, these people really mean to say:
> 'This program can be compiled with the Manx C compiler'.
> But why don't they say that, then???

Compile a non-trivial program using the Lattice C compiler.  Use no special
command line switches. Compile the same code using the Manx C compiler, again
with no special command line switches. Do they both successfully run?
Do either of the compilers break any significant rules as defined by
K&R?

Manx and Lattice seem to me to be clear enough when used as adjectives
describing two different implementations of a language in which so much
is left to the discretion of the compiler implementation.

-larry

--
"Intelligent CPU?  I thought you said Intel CPU!" 
        -Anonymous IBM designer-
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+

peter@sugar.uu.net (Peter da Silva) (11/27/88)

In article <1978@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
> Compile a non-trivial program using the Lattice C compiler.  Use no special
> command line switches. Compile the same code using the Manx C compiler, again
> with no special command line switches.

First, there is K&R 'C' and ANSI 'C'. Neither Lattice or Manx is full ANSI,
but both have extensions over K&R. These extensions don't match.

You don't make clear what a non-trivial program is.

If you restrict yourself to K&R (that is, write what's called a portable
program) and don't use any extensions or Amiga-isms, and don't depend
on any emulation of UNIX-isms that the Amiga doesn't properly support.

> Do they both successfully run?

Yes. Even if you use the Amiga libraries, so long as you don't use ANSI
declarations and are scrupulous about casting arguments to functions.

> Do either of the compilers break any significant rules as defined by
> K&R?

Depends on how you interpret the language in K&R about sizing of integers.
-- 
		    Peter da Silva  `-_-'  peter@sugar.uu.net
		     Have you hugged  U  your wolf today?

	          Disclaimer: My typos are my own damn busines#!rne

dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (11/28/88)

lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips (Larry Phillips) Writes:
:Manx and Lattice seem to me to be clear enough when used as adjectives
:describing two different implementations of a language in which so much
:is left to the discretion of the compiler implementation.
:
:-larry

	Such a general remark is not deserving.  Assuming you forget about
those specifics which are REQUIRED when one deals with lower levels of the
Amiga's OS, and forget about the tweeking one can do with various compiler
options, and just stick with the stuff provided by K&R and those parts of
the ANSI spec both compilers support, then they are compatible.

	You make it out like one or both have CHANGED the C language, which
isn't true at all.

	... back to those compiler options.  Since we are working with
microcomputers here there are many things we programmers must be allowed
to do to handle various situations which apply to microcomputers.  If the 
compilers did not have command line options to supply these, nobody
would buy them.

	For example, there is a clean split between those people who use
only 16 bit integers (mainly from the micro world) and those people who
use only 32 bit integers (mainly from the mini world).  There are even
people who would wish for 36+ bit integers but they make due with 32.  You
can't simply ignore half the crowd, now can you?  This doesn't apply to
larger computers because they have predetermined a lot of what we would
consider options on micros.

	Even so .. have you really looked at your UNIX compiler / linker
recently?  They've got equally incompatible options and extensions, though
very few people use them.

					-Matt

randy@bcsaic.UUCP (Randy Groves) (11/29/88)

In article <550@dover.uucp> fullmer@dover.UUCP (Glen Fullmer) writes:
>In article <7669@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>In article <5435@louie.udel.EDU> BPJ0%LEHIGH.BITNET@ibm1.cc.lehigh.edu (Binoy James, Lehigh University.) writes:
>>>I'm considering my senior project
>>> ...
>>	Buy the following items:
>>	Guaranteed Master's Degree:  Make this setup work with Starglider II.
>>
>>_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
>>Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
>
>New technology, old idea.  At the University of Utah they called it the
>"Sorcerer's Apprentice".  It also had a wand with which you could write in
>3-d space!  The only problem is that the monitors were small HIGH VOLTAGE CRTs

In the October 31 issue of Infoworld, there was an article in the new "Impressions"
section about the "Private Eye", not yet sold by Reflection Technology.  This is a
monocular eyepiece that displays "near-Hercules" resolution.  They are claiming that
they want to sell the device for under $100.  It is only monochrome now, but it seems
to me that the same idea could be adapted for use with color, and expanded to 
handle stereo vision.










-- 
-randy groves - Boeing Advanced Technology Center
UUCP:	..!uw-beaver!uw-june!bcsaic!randy     USNail: Boeing Computer Services
CSNET:	randy@boeing.com		              PO Box 24346 M/S 7L-68
VOICE:	(206)865-3424				      Seattle, WA   98124