HDTenEightyP/NetNews huggingface dataset:
From: kimberg@imada.ou.dk (Kim Berg Hansen)
Subject: Does a compiler for AmigaBASIC exist somewhere ?
Summary: Looking for a compiler for AmigaBASIC, or someone to make it!
Keywords: compiler, AmigaBASIC
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Fri, 18 Dec 1992 12:41:44 GMT

I'm not a tough programmer, but I like to fiddle around and make some things
myself. For this purpose AmigaBasic gives me practically all the things I need.

My problem is this: I'd like to create a few stand-alone utility programs for
some things I do fairly often. With AmigaBasic programs I have to have a disk
with AmigaBasic available in a drive - I cannot just have a program, whose name
I can type in Shell or make an icon for, and then it'll run.

Also it's fairly slow interpreting programs (as AmigaBasic does) rather than
compiling to a stand-alone machine-code or assembler program. I'd rather have
a compiler for AmigaBasic than the supplied interpreter.

So the question is : -> ->  Does a compiler for AmigaBasic exist somewhere ?

If yes :
   * Where can I get it? (Company name, if commercial -
                          FTP-site or Fish-disk, if PD.)
   * What's the price?   (If commercial.)
   * How good is it?     (Subjective evaluation.)

If no :
   * Would it be possible to make such a compiler?
   * Is there anybody but me interested in such a creation?
   * If we are enough interested people, is there a programmer willing to
     tackle the problem?

Thank you for any response .   ('cept flames ;-)


Kim Berg Hansen            |       ' JEHOSHAPHAT !! '
kimberg@imada.ou.dk        |             - Plainclothesman Elijah Bailey
From: chucks@pnet51.orb.mn.org (Erik Funkenbusch)
Newsgroups: comp.sys.amiga.programmer
Subject: GadTools and Boopsi
Date: 11 Dec 92 21:25:00 GMT
Organization: People-Net [pnet51], Minneapolis, MN.

I assume that GadTools is built ontop of boopsi.  Is it possible to use the
boopsi Methods with GadTools?  For instance, the  can i use the ICA_TARGET
tag?
 
Or must I create Boopsi objects in order to use this? 

.-----------------------------------------------------------------------------.
| UUCP: {crash tcnet petrus quest}!orbit!pnet51!chucks | Amiga, IBM, and any  |
| ARPA: crash!orbit!pnet51!chucks@nosc.mil             | system you let me    |
| INET: chucks@pnet51.orb.mn.org                       | get my grubby mind   |
|------------------------------------------------------| into.                |
| Programmer at large, employment options welcome, inquire within.            |
Xref: sparky comp.sys.amiga.programmer:17584 comp.sys.amiga.hardware:21836
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 17 Dec 92 20:44:43 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Distribution: world
Organization: Commodore, West Chester, PA

In article <1gnl0mINNpq2@crcnis1.unl.edu> tbills@cse.unl.edu (Trent Bills) writes:
>|> Another Advantage of RISC is the abundance of Register memory.  

>Since most microprocessor computers have either on chip or external caches,
>register access really isn't much if any faster than memory access.  

Sure it is.  It wasn't until recently that on-chip caches hit as fast as 
register accesses -- this is true for the 68040 and some RISCs, but hits to
the on-chip caches on 68030 and 80486 take twice as long as register access.
External access, even to cache, will take longer.  Even if there's a very fast
external bus interface, you're still having to occupy the bus interface with a
data cycle if you can't use a register.  When you can use a register, the 
external bus interface may be free for I or other D fetch.

But it's actually even worse than that.  Registers are often multiported, 
sometimes four-way or more.  Multiple execution units can have simultaneous
read access to a register, effectively cutting it's access time by the 
degree of multiporting.  The next generation of on-chip caches are moving 
toward interleaving or 2-way porting, but they're still much less efficient
than registers by several times.

>It is important to note that RISC processors that have > 32 registers do
>not have the use of all of these registers simultaneously.  The processor
>only has access to a few (24-32) at a time.  A compiler can then place
>parameters for function calls in the last few registers.  When the
>function call is executed, the CPW (current window pointer) is changed
>so that the registers that were previously the last few are now the first
>few.  This parameter passing technique avoids using the stack (slow memory)
>and thereby drastically reduces the cost (time) of a function call.

This is the approach taken by the SPARC processors.  You can have a function
call advantage, but it can mean that context switches are really expensive.
An interesting alternative approach is used by the AT&T CRISP architecture.
Rather than avoid using the stack, they count on using the stack and put in
what's essentially a stack cache.  Operations run stack-relative, but cached
stack entries behave like registers (since stack cache hits take place in 
their own cache, not the D cache, there are no inherent conflicts with other
data fetches that may go on, just like traditional register access).  The
advantage of this is that, like any other cache, only the dirty values need
to be written out on a context switch (or none if you're running with a 
write-through cache).


-- 
Dave Haynie / Commodore Technology, High-End Amiga Systems Design (cool stuff)
 "The Crew That Never Rests"  {uunet|pyramid|rutgers}!cbmvax!daveh   BIX: hazy
		SCIENCE:	"I'll believe it when I see it"  
		RELIGION:	"I'll see it when I believe it"

Newsgroups: comp.sys.amiga.programmer
From: pochanay@cae.wisc.edu (Adisak Pochanayon)
Subject: Re: RUN BYTE! RUN!
Organization: College of Engineering, Univ. of Wisconsin--Madison
Date: 17 Dec 92 08:08:58 CST

In article <JRAJA.92Dec17102659@vipunen.hut.fi> jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) writes:
>In article <1992Dec15.213400.28437@doug.cae.wisc.edu> pochanay@cae.wisc.edu (Adisak Pochanayon) writes:
>
>	    XDEF @UnPackByteRun
>   @UnPackByteRun:
>
>	     move.l    d2,-(SP)       ; Move #7F to d2 so that the and.w
>	     move.b    #$7F,d2        ; instruction at the upb_copyit label
>	     ^^^^^^^		      ; will execute more quickly
>
>this should be at least word size, or even better moveq.l could be used.
>Byte transfer only will trash the value of the counter in 'upb_copyit'.
>
>	     bra.s     upb_startit    ; Process First byte-tag
>
>
>   *********************************
>
>   upb_copyit
>	     and.w     d2,d0          ; Clear bit seven in d0
>	     ^^^^^
>
>This is the point of trouble if only 8 bits are loaded to d2.
>
>
>	Jarno
>-- 
>-----------------------------------------------------------------------------
>| Address: Jarno Rajahalme            | EMail:                              |
>|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
>|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
>-----------------------------------------------------------------------------
>
>

     If you notice, I at upb_startit

upb_startit
          moveq.l   #0,d0          ; Require to clear MSB of d0 for dbf loops
                                   ; Which is $FF after dbf loops

          move.b    (a0)+,d0       ; Load byte-tag into d0 and test byte-tag

    Therefore d0 always has a byte value only (upper 24 bits are 0).

upb_copyit
          and.w     d2,d0          ; Clear bit seven in d0

   When the above and is executed, it doesn't matter what is in the highest
24 bits of d2 because the highest 24 bits of d0 will be guaranteed to be
zero.  If you really want to avoid confusion, change the and.w to and.b
although it won't have any effect on the code.  The code works perfectly as
posted and is in several of my games including my most recent FreeWare game
"znykdist.lha" which is on wuarchive and physik.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: A few Handler/FileSys Q's (Mod.Long.)
Date: 18 Dec 92 04:59:59 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Keywords: handler filesystem packets Amiga DOS AmigaDOS lock FileLock

djung@economics.adelaide.edu.au (David Jung) writes:
>First here's what I have discovered ... a scenario ...

[ opens file, notices that if the disk is removed and then another read
  from the file is done, the system requests it be replaced in the same drive ]

	This is normal behavior for our FS, because of it's implementation.
Filehandles, unlike locks, are actually handles on coroutines inside the
filesystem.  Locks can easily move from one machine to another.  Coroutines
can't in general.  The guts of the FS (actually almost all of it) would
have to be recoded from scratch to change this.

>3) As a filesystem, if a volume has just been inserted into the device you're
>managing, and you grab the locks from the dol_LockList, can you Forbid(), go
>through and change the fl_Task field of all the locks to yourself, then Permit()
>so that any further use of the active FileLocks will be directed to you?

	Yes, this is expected.

>4) If, again as a filesystem, I get an argument FileLock for a volume I am
>no longer managing (volume was ejected from my device), can I, upon inspection
>of the DosList finding a non-NULL dol_Task field, send the packet onto
>the other filesystem that is managing the volume now (assuming the dol_Task
>field is non-NULL because the volume has been inserted into another device).
>I would have to set up the packet so it was returned either to me, or directly
>to the application/DOS.

	You could do this, I suppose, but it would be more normal to fail it.
Be very careful when forwarding packets about dp_Port.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: kontos@clipper.ingr.com (Thorne Kontos)
Newsgroups: comp.sys.amiga.programmer
Subject: Big mistake - A compromise (of sorts)
Keywords: Lack of new AGA hardware manual
Date: 18 Dec 92 21:12:23 GMT
Organization: Intergraph Advanced Processor Division - Palo Alto, CA


     Since I believe I started this thread, let me put forth a compromise
solution. There are two classes of people who will continue to write
software for the Amiga. The professional programmer who is attempting to
create a piece of software that may become a viable commercial product 
is one of these. The other is the hardware hacker/demo coder who writes
"demos" for fun. The obvious solution given that Commodore does not wish
to release the AGA specs, is to release code that will allow the hacker
to bang the hardware, yet return to the normal OS when the demo is 
finished. A generic piece of code that covers all Amigas (regardless of
configuration) would be perfect. In this manner, the demo coders can happily 
bang the hardware all they want, but by using this snippet of code, the
computer can be returned to its "normal" state, without having to do 
the three finger salute and reboot the machine which is so prevalent among
the current demos that I have seen. So what do you think? 
     IMHO, this solution works well, and satisfies all. Commodore does not 
have to release the AGA specs. Demo coders will be able to continue to code
demos, but they will be OS friendly demos. Professional programmers can and
will continue to use the normal OS function calls.

                                                     Thorne K. Kontos
                                                     System Engineer
                                                     Intergraph A.P.D.
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Where is Matt Dillon?
Date: 14 Dec 92 19:53:54 GMT
Organization: Edotronik GmbH

Does anybody have a _working_ email address of Matt Dillon?

I want to ask him a copyright and distribution question concerning his DME,
but failed so far to reach him. The mail didn't bounce, though :-((((
I don't like illegal things, so I'd like to ask first.

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: koren@fc.hp.com (Steve Koren)
Subject: Re: CISC and RISC
Date: Mon, 14 Dec 1992 15:06:32 GMT
Organization: Hewlett-Packard Fort Collins Site
X-Newsreader: Tin 1.1.3 PL5

> Why should computer makers go from CISC to RISC?
> 
> I was under the impression that CISC meant complicated instruction set
> and RISC meant reduced instruction set. So wouldn't that mean larger
> code size on a RISC machine compared to CISC.
> 
> What are the advantages of CISC and RISC?

This probably isn't quite the right place to ask about this - maybe one
of the comp.*  architecture groups would be better.

Anyway, briefly, the answer is "it depends". :-)

Today's commonly available hot RISC chips (ie, DEC Alpha, HP-PA, etc.),
are faster than today's common CISC chips (68040, 486, etc.), by a good
margin.  That's why manufacturers use them.  But people obviously still
buy CISC machines, even when a faster RISC machine is available, so
there are obviously good reasons to use CISC.

Anyway, there are popular RISC chips today which are slower than 68040s,
and for all I know, there is some CISC chip out there faster than a fast
DEC Alpha or HP-PA chip.  (The 586 and 68060 should come close to if not
surpass today's lower end Alpha and PA-RISC machines.  Already a 68040
comes within about 4X of an HP 720 for floating point performance).

The "larger code size" thing you mention shows up a little bit, but
often its not too bad.  I just did a quick comparison some of 68K vs
HP-PA binaries from the same source code, and the RISC version tends to
be about 25% larger on average.  However, the worst case was almost 3X,
for a small binary.  And its certainly architecture and compiler
dependent.  You may get different results from an IBM RS/6000, say.

Some reasons a manufacturer might want to stay with CISC?  Binary
compatibility with old applications.  That's a big one.  Or if you're
doing assembly programming, CISC chips tend to be much easier to deal
with than RISC, which are only designed to be programmed via compiler.
(Not that it can't be done, it is just less straightforward, and you
have to remember funky rules like what happens if you have an
unconditional branch in the delay slot of a conditional branch, and
other far-out things).  Also, if you currently have a 68K based design,
its a whole lot easier to come up with a new 68060 based system than it
would be to go to a RISC chip of any sort.

Some reasons a manufacturer might want to go to RISC?  Cutting edge
single-chip performance.  Probably some others I haven't thought of.

BTW, "RISC" is a bit of a misnomer given the chips we label as RISC
today.

Assuming Motorola comes through with the 68060, I think Commodore won't
have any compelling reason to move to RISC.  68K won't give cutting edge
performance, but heck, it doesn't do that _now_.  It will be good enough
for a long time, though, especially for the PC world which doesn't tend
to be performance-critical.  After all, how many people out there still
get along just fine with 68000s and 286s?

  - steve "if you want leading edge workstation performance from a PC
           class machine, buy 4 or 5 of them"
From: beust@modja.inria.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Small database package
Date: 10 Dec 92 09:33:36 GMT
Organization: University of Nice Sophia-Antipolis, France


	While writing a program, I happened to need badly a generic way
	to handle data. So I decided to write a small generic module
	that helped me a great deal. It occured to me that if someone
	had posted this kind of thing on Usenet, it would have saved
	me some development time. That's why I'm posting the header
	of the module. It should be enough for any programmers to decide
	whether they need it or not.

	Depending on the interest, I'll wrap a distribution and make it
	available on ftp site (or by mail, it's very short), so let me
	know if you're interested.

	I won't insist on the Genericity interest, nor the "abstract
	type" concept. All you have to know is that you can change
	the implementation to improve it and you won't have to modify
	your programs...

	One last point : the database module is completely dynamic and
	will only be limited by your memory.

	The excerpt from the header file follows.


--
Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.



/* Generic module to handle dynamically allocated database */

DataBase
DB_NewDataBase(int size);
/* Initialize a new database, which objects have size 'size' */
/* Alter the internal pointer */

Bool
DB_EndOfDataBase(DataBase db);
/* True if we reached the end of the database */

void
DB_ClearDataBase(DataBase db);
/* Clear the database */

Bool
DB_AddEntry(DataBase db, Generic entry);
/* Add the following entry into the database */
/* Return 0 if the operation was successful */

Bool
DB_RemoveEntry(DataBase db, Generic entry);
/* Remove the specified entry */
/* Return 0 if the operation was successful */

Bool
DB_RemoveNthEntry(DataBase db, int n);
/* Remove the nth DB_NextEntry from the database (0 = first entry) */
/* Return 0 if the operation was successful */

Bool
DB_ReplaceEntry(DataBase db, Generic old, Generic new);
/* Replace the old entry with the new one */
/* Return 0 if the operation was successful */

void
DB_Rewind(DataBase db);
/* Rewind the database so that a subsequent NextEntry returns the */
/* first occupied element */

Generic
DB_NextEntry(DataBase db);
/* Return the next entry, or NULL if we reached the end of the database */

Generic
DB_NthEntry(DataBase db, int n);
/* Return the nth "DB_NextEntry" of the database (0 = first entry) */

int
DB_Count(DataBase db);
/* Return the number of entries in the databae */

void
DB_Sort(DataBase db, int (* compareFunction)(Generic a, Generic b));
/* Sort the database, so that */
/*     compareFunction(DB_NextEntry(db), DB_NextEntry(db)) < 0  */
From: jam@jammys.ocunix.on.ca (James McOrmond)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:  How to Mungwall ?
Distribution: world
Date: 13 Dec 92 19:29:24 EST
Organization: Jammy's Amiga Corner BBS - Ottawa, On, Canada

>>> How do I get mungwall to display its output to the shell (or any) window?
>>> 
>>Maybe you can redirect the serial.device via CMD to a file or shell.
>
>As I remember, mungwall writes direktly to the ports, or something similar,
>without using any device.
>Catch your output with sushi.

Yes, Sushi is definately the best software solution.  There are a few
interesting hardware solutions though.  The most obvious is sticking a
9600bps dumb terminal off of the serial port, which is of course what the
software is designed for :-)  Or, if you have a number of serial ports
(something like an A2232 board), you can actually null-modem the
information back into the system.  This is what I was doing for a long
time, with JRComm, or some other terminal program setup to receive the hit
messages.

--
 James A McOrmond - Ottawa, Ontario, CANADA! - ZyXEL 16.8k V32bis Modem!
 Fidonet#1:163/165.0 - (613)521-0648 - VBBS Amiga Intuitionized BBS
 UUCP: Jam@Jammys.OCUnix.On.Ca - Amiga 3000T/25/5 - 383Megs
From: Jesse_Michael@matrix.rain.com (Jesse Michael)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 15 Dec 92 17:51:23 GMT
Organization: The Matrix BBS

In a message dated Sat 12 Dec 92 14:17, Ejad-A@minster.york.ac.uk wrote:

>Is it necessary to go all or nothing for either the OS or hardware
bashing?
>Why do h/ware bashers look down on OS programmers and vice versa? It's
just
>the way you choose to do things. So why the hostility? As long as nobody
>gets hurt, it's OK. I do think though that commercial programmers have a
>*responsibility* to ensure their programs are OS friendly. Demo coders
don't
>have a similar responsibility...

I don't think the OS is bad, it's just a problem of using the right tool
for the job.

If I want to write a utility, I go completely through the OS.

But, if I want to write a program with _fast_ inconvex filled vector
objects, the overhead of the OS causes too much of a performance hit.

I think that if someone uses hardware-level code in a commercial
application that doesn't need it (e.g. a word processing program) then they
deserve all the problems it causes them.

>In the end of it we just have to put up with what C= choose, and if they
>think
>it's best for the Amiga, 'tis so.

But, when it's something that will ultimately *hurt* the Amiga, then we
have the responsibility to *try* to point it out.

I think they should release hardware references in the future, *but* they
must provide a good example of how to *really* use the hardware.  Not like
the examples in the old hardware reference manuals.  (e.g. absolute
addressing)

-Jesse

-- Via DLG Pro v0.995

--
Haze of Epsilon / Check out Epsilon for the best in NTSC demos!  Ok, so if
you compare us to groups like Anarchy and Silents then we're lame, but what
the hell do you expect from us lazy Americans?!?  :^)
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.amiga.programmer
Date: Fri, 18 Dec 1992 20:05:57 -0500 
From: Michael Witbrock <mjw+@cs.cmu.edu>
Subject: OK SAS 2 users 0
	<BzGJM3.IB8@unx.sas.com>
Distribution: comp

Excerpts from netnews.comp.sys.amiga.programmer: 18-Dec-92 Re: alleged
Bug in SAS/C V6.. Doug Walker@twix.unx.sas (1903)


> Reread your K&R quote about the ~ operator:  "The default integer promotions 
> will be performed" or some such statement is in there.  The default integer 
> promotions are:

>    char           -> int
>    unsigned char  -> int
>    short          -> int
   unsigned short -> int

Oh.... I didn't follow the pointers in K&R's barely tractable prose that
far, since, fortunately, *I* don't work for a compiler company :-)

So, now that SAS has proven beyond a shadow of a question that 

x= ~0; 
is wrong if sizeof(x)<sizeof(int)   .... could someone please tell the
author of gadtoolsbox so that he can fix the code generator (in fact,
could someone let him test it thoroughly on SAS C, since it seems to be
fiercely pedantic, and therefore *A GOOD THING*).

Michael (who doubts that being told by SAS/C that your ~0 is too long is
as galling as being told (with evident contempt in its ... voice ) by a
CRAY-YMP  that "your program apears to be a scalar code".
From: beust@aurora.unice.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Emacs and SAS/C
Date: 18 Dec 1992 09:20:21 +0100
Organization: University of Nice Sophia-Antipolis, France
Distribution: world
NNTP-Posting-Host: aurora.unice.fr



Peter Sj|str|m writes :

>	I use elisp code to compile and jump to errors from within emacs.
>Here's my elisp code. It's compile.el and compile-ok.el. load compile-ok.el
>after you have loaded compile.el into emacs. Hope you don't need more of
>my elisp code. I am thinking of uploading a whole package soon, so
>hold on. You will have to guess a bit to adapt it to your own disks...

	On a related topic, I've almost finished to adapt gnuemacs' gdb
	package to work with CPR (it will probably be finished when
	you read this message).

	I don't understand why you need a personal compile.el package to
	compile, Peter? The default compile-mode and error-parsing
	mechanism work like a charm without the least modification. I didn't
	take a look at your code, did you improve them?

	I will possibly upload cpr.el to the usual ftp sites once it gives
	me satisfaction and if there's interest in it, so let me know.

--
Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.

Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware