HDTenEightyP/NetNews huggingface dataset:
From: aduncan@rhea.trl.OZ.AU (Allan Duncan)
Subject: Re: Multithreaded code using CreateTask()
Organization: Telecom Research Labs, Melbourne, Australia
Date: Thu, 1 Oct 1992 23:35:52 GMT

I won't try and quote this one - it was getting too nested.

If you are using Manx 3.6 (I can't say what 5.xx does) all the library
calls of note use stubs that have a global library base vector loaded
into a6 (eg graphics library calls load GfxBase into a6).  Therefore any
subtask you run will be using the values you got when you opened the
libraries in the main program, and you had better not close the library
before you have shut down the subtask!

I am defining a subtask as something run in conjunction with the main
program, not a free entity.  In that case, you also get the question of
who owns the memory allocation for the global library base vector.
Allan Duncan		ACSnet	 a.duncan@trl.oz
(+613) 253 6708		Internet a.duncan@trl.oz.au
Fax    253 6664		UUCP	 {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan
    Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
From: beust@capa.inria.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: What the programmers need...
Date: 29 Sep 92 13:43:40 GMT
Organization: University of Nice Sophia-Antipolis, France

In article <Bv1AGD.Kn3@unx.sas.com>, walker@twix.unx.sas.com (Doug Walker)
writes:

>Have you looked at my memory debugging library (called "memlib.lzh" on
>the boards I've seen it on)?  An early version is on a Fish disk, and
>several revised versions have been around; one was featured in the
>AmigaWorld Tech Journal.  It gives messages like this:

	Yes, I remember having used it a long time ago. I will
	get the latest version. Good thing you reminded me it existed.

>CPR's breakpoints don't slow down the program noticeably.  I don't
>know what you mean by "watchpoints" - if you mean checking a variable
>every so often, you can do this in CPR:

	Yes, that's what I meant. Unfortunately, I can't afford CPR
	but I'm beginning to think it is a great debugger.

>C= does provide routines to manipulate lists (quite good ones, actually).
>All of Exec is based on them.  The standard C library provides routines 
>to manipulate strings.  As for trees, that would be nice... I'd like to
>see a good btree shared library out there...

	Yes, I've used all that (but I don't see what you mean about
	strings). It's good but not satisfactory compared to the object-
	oriented approach. Don't get me wrong : I'm not saying OOP
	is the key to all the problems, only that it is most useful for
	this kind of low-level programming.

	I'm really beginning to think that calls to malloc() shouldn't
	exist any more. I guess it will be done when C becomes obsolete.

	Year 2000 or so :-)


+------------------------------------------------------------------------+
| Cedric BEUST                                     University of Nice    |
| INET: beust@avahi.inria.fr                       $whoami               |
| UUCP: llaor.unice.fr!arkonis!beust               god (personal alias)  |
|    //      -- "To be, or not to be...",                                |
| \\// Only    That is illogical, captain!         f U cn rd dis         |
|  \/ Amiga!                 -- Spock              U mst uz Unix         |
+------------------------------------------------------------------------+
Newsgroups: comp.sys.amiga.programmer
From: omega@sabrina.dei.unipd.it (Piero Filippin)
Subject: Problemi con il 2.0
Organization: D.E.I. Universita' di Padova -- Italia
Distribution: ita
Date: Mon, 28 Sep 1992 17:18:51 GMT

Organization: D.E.I. Universita' di Padova, Italia
Keywords: 

Molti programmi mi danno problemi di memoria:mancate allocazioni,guru 
dovuti alla ramlib...(soprattutto sono giochi). A cosa e` dovuto?

Si puo` rimediare?
From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HDMem vs GigaMem for virtual memory on Amigas?
Date: 5 Oct 92 16:19:05 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

In article <1992Oct3.063217.16317@mnemosyne.cs.du.edu> chanson@nyx.cs.du.edu (Chris Hanson) writes:
 >
 >  Also, even if it were 68040 compatible, it would not work on the A4000,
 >as the A4000 uses the 68EC040 chip, the big brother of the 68EC030. The
 >68EC040 chip has neither PMMU nor FPU math coprocessor. 

Hmm, don't have an open A4000 just besides me, but I remember Dave H
stating several times here that the A4000 has the *full* 68040, not
the EC variant.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
From: beust@modja.inria.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: The RKM doesn't say everything about iffparse?
Date: 2 Oct 92 14:26:56 GMT
Organization: University of Nice Sophia-Antipolis, France


	Well, it seems to. I read the chapter over and over again but
	I didn't find any mention or explanation for the behavior I met
	and that I will describe quickly right now...

	It seems that IFFParse() in any mode wants to find precise
	header chunks, or it will die with a very obscure reason
	(-5, or rather IFF_READERR). If I try to read an IFF file
	like this :

FORM xxxx ILBM BMHD

	it works but

FORM xxxx DUMM BMHD

	fails.


	I wanted to use a personal hunk but I have to use a pre-defined one
	(FTXT to be precise). And when I say pre-defined, it's not
	quite true since you have to create the header yourself with MAKE_ID.

	So... Are chunk names like ILBM, FTXT hard-coded in Rom?


--
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.
From: jow@hcast.adsp.sub.org (Juergen Weinelt)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hidden-Poly removal
Date: 27 Sep 92 10:51:01 GMT
Reply-To: swb.de!imart!hcast!jow
Organization: Private UUCP Site

In article <1992Sep24.085341.24751@bristol.ac.uk> ccsw@bristol.ac.uk (EthaStorm) writes:
>
>Try the "Painter's Algorithm/Theorem". Work out the depths (distance from
>eyepoint) of each polygon. Then draw them in order of most distant first,
>nearest last.

It's simple and elegant, but there are some problems with it.

(1) If there are many polygons, but only a few of those are visible while
    the rest are obscured (just imagine a 3D maze), it may be quite slow.

(2) If there are polygons that penetrate each other, it will not work
    properly. You have to split those into smaller, non-penetrating
    polygons first.

>EthaStorm  *8)

-- Juergen

  o  _         Juergen Weinelt, Germany
  | (_) \/\/   UUCP: swb.de!imart!hcast!jow
  '            CBMNET: jow@hcast.adsp.sub.org
From: jordan@castor.cs.uga.edu (USENET's Chuck)
Newsgroups: comp.sys.amiga.programmer
Subject: Opinions on AMOS?
Date: 4 Oct 92 20:40:25 GMT
Organization: University of Georgia, Athens
Originator: jordan@castor

I've been living in a cave for the past few months (Conyers, GA, to be
exact) and haven't heard anything about AMOS, except that it's supposedly
good for writing games.  Could anyone out there give me (preferably E-mail,
since I would guess a lot has already been posted about it) an idea of what
it's like and what are your opinions of it?  How powerful is it -- the
impression I got was that it was basically a souped-up Amiga-specific version
of BASIC.  Is the compiler included with the basic package?  What kind of
speed would I be able to expect from a program written in AMOS?  (Is it
suitable for adventure/RPG or strategy games only, or is it possible to 
write an arcade-style game in AMOS?)  Should I stick with C?

Thanks much,
USENET'S Chuck

-- 
                  Chuck Jordan | jordan@castor.cs.uga.edu
SPY Magazine's 1,000 Reasons Not to Vote for George Bush:
NO 964: The president wants to spend $1,000 per person for defense in
	fiscal 1993.
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: HELP: Prog. will not compile with STDLIB.H : Why? Anyone?
Originator: walker@twix.unx.sas.com
Date: Thu, 1 Oct 1992 13:25:20 GMT
Organization: SAS Institute Inc.


In article <1992Sep30.180814.7945@scic.intel.com>, gatlin@scic.intel.com (Robert Gatlin) writes:
|> I am having trouble compiling any C file with the statement:
|> 
|>   #include <stdlib.h>
|> 
|> The error appears to be concerned with the defintion of main
|> in the stdlib.h file and main in my program:
|> 
|>   main()
|>   {
|>     ... Code Here ...
|>   }

What does the declaration in the include file look like?  Make your
function definition match.  It's probably something like

   void main(int argc, char *argv[]);

or

   int main(int argc, char *argv[]);

Simply declare your main() exactly as it is declared in stdlib.h and
you will be OK.  Oh, if stdlib.h doesn't include names for the 
parameters like I did above, you'll have to add them - in other words,
it might have

   void main(int, char *[]);

and you would have to add the "argc" and "argv".

Another "copout" method is to do this:

#define main junk
#include <stdlib.h>
#undef main

main()
{
}

This makes the declaration of main in the header file look to the
compiler like the declaration of a function called "junk", but then
gets out of the way when it's time for you to define main.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Multithreaded code using CreateTask()
From: brycerw@brandonu.ca
Date: 2 Oct 92 10:07:02 CST
Organization: Brandon University, Brandon, Manitoba, Canada

In article <35483@cbmvax.commodore.com>, dlarson@cbmvax.commodore.com (Dale Larson - Product Assurance) writes:
> In article <1992Sep30.131753@uni-paderborn.de> aurel@uni-paderborn.de (Aurel Balmosan) writes:
>>In article <paulk.1okg@terapin.com>, paulk@terapin.com (Paul Kienitz) writes:
>>|> > Sure, but even then it isn't legal to access library bases that
>>|> > were openened by another task.
>>|>  
>>|> Okay, the subtask can access the main program's global variables except for
>>|> library bases.  But SysBase, at least, it can go ahead and
>>|> use because there is guaranteed to be only one value for that.  It
>>|> can go ahead and use that for opening the other libraries.
>>
>>I think (and i know it because i use in my projects) you can use any library
>>bases which was opened in the main process,
>>because the library base pointer is always the same, only the open counter
>>in the library will be changed. So if you don't close the library in a slave
>>process it may work fine. 
> 
> Wrong.  Some libraries return different library bases to each opener.  To my
> knowledge, no library other than Exec has guaranteed that it will always return
> the same library base to each opener, though this is (and probably will
> continue to be) the usual behavior for many libraries.  Be safe and re-open
> any libraries needed by the child task or process.
> 
> 
> -- 
> -------------------------------------------------------------------------------
> Dale Larson, Software Engineer,    |
> Commodore, Systems Assurance Dept. |    "Bridge, this is Riker.  If you need 
> (Amiga Systems Group)              |     me, I'll be in Holodeck 4."
> dlarson@commodore.com              |       -after resisting a female metamorph

Ok, what's the trick to doing this.  In my program, I have one main process to
open up libraries (right now), and help co-ordinate communications between
spawned processes and tasks.  I have a matching spawned task for each spawned
process, and I can have many instances of these - running the same code.  So
at any time I have 2n spawned tasks, 2n spawned processes, and the main 
process.  I have exactly one global variable, pointing to a global structure
which forms a linked list to other various structures, of which parts are
shared.  I am currently using SAS 5.10a, with version 6.0 on the way.  How
should I declare the global variable, library pointers, set complier flags, 
etc. to:
    (a) be able to keep that one global variable so it can be found and
	accessed properly by all spawned tasks and processes;
    (b) be able to run n instances of a task or process over the same code;
    (c) open/close libraries for each process/task as I am supposed to.
Right now, the way I've got it set up, everything is working fine with the
spawned processes/tasks sharing the the library pointers openned by the main
process.  But I want to get it right.

Inquiring minds want to know....

Robert Bryce
BRYCERW@BrandonU.CA
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: Comeau C++
Newsgroups: comp.sys.amiga.programmer
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 25 Sep 92 23:01:36 PST
Organization: Missionaria Phonibalonica

In <Bv645s.31L@well.sf.ca.us>, comeau@csanta.attmail.com (Greg Comeau) wrote:
> In article <jac.717141769@moonshine> jac@moonshine.llnl.gov (James A. Crotinger) writes:
> >lkv@mania.hotb.sub.org (Lutz Vieweg) writes:
> >> Don't you think this point is an _essential_ drawback in
> >> comparison to other C++ compilers, thinking of GNU C++ for example?
> >
> >  This subject has been re-hashed a zillion times in C++ groups,
> >compiler groups, etc.  Experience has shown that using CFRONT is
> >certainly NOT an "_essential_" drawback.  It is true that there are
> >some optimizations which would be easier to do with a native code
> >compiler; for example, inlining more kinds of functions, and
> >eliminating temporaries in certain situations (some of these
> >optimizations can also be done by making CFRONT smarter, and I believe
> >CFRONT 3.0 is supposed to be better about this than past versions).

The conclusion I last heard was that generating C code meant the
compiler vendor could concentrate on higher-level optimizations
instead of machine-specific, low-level stuff. The developers who did
the study figured it came out at about the same speed in the end. This
actually leaves the CFRONT people with an advantage, as they have two
groups working on optimizing the compiler - themselves doing the
high-level stuff, and the C compiler vendor(s) doing machine-specific
stuff. I'd expect that recompiling Comeau++ products with SAS/C 6.0
will show a major improvment, with no work from Comeau.

> Moving right along ;-), the reviewer also found that we compiled faster than
> some of the native code compilers.

Was that also with you having the optimizer turned off and the native
code compiles having it turned on :-) ?

[g++ not being ANSI...]
> >However, whether they like it or not, CFRONT is the de facto standard,
> >and I believe it is not too much to ask that other compilers at least
> >be up to the CFRONT 2.1 level by now.

Well, if you really want g++ to have some features and can't convince
anyone else to add them, you have two options: 1) do it yourself or 2)
Pay someone else (like Cygnus Support) to do it for you. The advantage
of copylefted software is that option 1 exists, whereas it doesn't
with most commercial software. The disadvantgae is that you can't
threaten the sales of the compiler vendor if you aren't happy with
them.

	<mike
From: jmpor@dynam.adsp.sub.org (Jean-Marc Porchet)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: The RKM doesn't say everything about iffparse?
Date: 3 Oct 92 16:48:48 GMT
Reply-To: cbmehq!cbmswi!dynam!jmpor@cbmvax.commodore.com
Organization: Merging Technologies (IV-24 designers)
X-Newsreader: Arn V1.00 beta rel2

In article <30755@sophia.inria.fr>, Cedric Beust writes:

> 	It seems that IFFParse() in any mode wants to find precise
> 	header chunks, or it will die with a very obscure reason
> 	(-5, or rather IFF_READERR). If I try to read an IFF file
> 	like this :
> 
> FORM xxxx ILBM BMHD
> 
> 	it works but
> 
> FORM xxxx DUMM BMHD

Here is a small example that read the IV-24 prefs :

#define ID_IV24		MAKE_ID('I','V','2','4')
#define ID_IVGB		MAKE_ID('I','V','G','B')
#define ID_IVSP		MAKE_ID('I','V','S','P')



	IFF->iff_Stream = File;

	InitIFFasDOS(IFF);

	if(!(IFFOpen = (OpenIFF(IFF, IFFF_READ) == 0)))
		goto Error;

   /* Get the IVGB chunk in the PREF FORM */
	if( PropChunk( IFF, ID_PREF, ID_IVGB ) )
		goto Error;

   /* I want to stop at the end of the PREF form */
	if( StopOnExit( IFF, ID_PREF, ID_FORM ) )
		goto Error;
   
   /* I parse the file */ 
	if( ParseIFF( IFF, IFFPARSE_SCAN ) <-2)
		goto Error;

   /* I look if I've found a IVGB chunk */
	if( ( Prop = FindProp( IFF, ID_PREF, ID_IVGB ) ) == NULL )
		goto Error;

   /* I copy it in a safer place */
	memcpy( &Digi, Prop->sp_Data, sizeof(struct DigiConfig) );

	Error: /* Hoops an error or the end */
	if(IFFOpen) CloseIFF(IFF);
	if(File) Close(File);
	if(IFF) FreeIFF(IFF);



If you still have questions, send me an email (French is also fine).


--

PS : forgive my bad English, I'm still trying to learn it
-----------------------------------------------------------------------------
Jean-Marc "JUMP" Porchet                             Phone : (41) 22-754-1733

EMAIL :   ...{uunet,rutgers}!cbmvax!cbmehq!cbmswi!dynam!jmpor
	       or try   mcsun!cbmswi!dynam!jmpor		 
-----------------------------------------------------------------------------
'Simple things should be simple & complex things should be possible' Alan Kay
Newsgroups: comp.sys.amiga.programmer
From: robart@agora.rain.com (Robert Barton)
Subject: Re: E-mail on "Re: Comeau C++"
Organization: Organization
Date: Mon, 28 Sep 1992 22:55:10 GMT

In article <BvAx71.vJ@well.sf.ca.us> comeau@csanta.attmail.com (Greg Comeau) writes:
>BTW, I just wanted to say quickly that an extraordinary higher than normal
>amount of e-mail that I am responding to is bouncing.  Discarding that I
>am paying for initial and duplicate messages... discarding that some messages
>are taking me as long as 1/2 hour to respond to... a number of you are sending
>nasty message that I have not responded.  Of course, when I answer that, it too
>bounces.  And so a vicious cycle.  Although I prefer public messages so that
>all can benefit from the dialogue, I do feel responsibility in not only
>responding to *every* message sent to me, but I feel responsible to answer
>it at least in full (I even answer things you do not ask).  For this I hope
>host denied.  Please find out if your maps are ok, and whether an outsider


  How about a specific newsgroup for Comeau C++, since very few of the
messages on this topic really have anything to do with Amiga programming?
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AztecC 5.2 and system()
Date: 5 Oct 92 11:45:45 PST
Organization: BBS

> I've also noticed that the system() call is not documented in my
> Aztec C documentation.  Does anyone know if the call is supposed to
> work under Aztec C and what its limitations are?  --
 
Hm, it does seem to be in the link library, but I can't get it to do
anything either.
 
If you're making a 2.0 program you should probably replace it with
SystemTags().
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Multithreaded code using CreateTask()
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Wed, 30 Sep 1992 22:44:18 GMT

In <1992Sep30.171327.3155@samba.oit.unc.edu> Todd_Lewis@unc.edu (Todd M. Lewis) writes:
>This poses some interesting problems.  Typically the Task's library base  
>pointers are shared with the parent Process.  What clean mechanism can you
>suggest for keeping multiple sets of these library base values in one set
>of base pointers?  I've really gotten into multithreaded code in a big way
>lately, and doing what you suggest would put a big kink in some of my
>current projects.

It may create problems when _existing_ libraries would require different
behaviours, but new libraries can of course require separate OpenLibrary
calls without doing any harm.

>written "by the book."  Following this new guideline would make
>CreateTask() almost useless for any significant subtasks given the
>way most compilers handle A6 for library calls. 

Well, some compilers allow library based to be kept as local variables.
And without that feature it is a matter of different stub routines
in amiga.lib and otherwise using the same measures as for reentrant
code.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: sunil@lsl.co.uk
Newsgroups: comp.sys.amiga.programmer
Subject: Re: I wouldn't mind finding out...
Date: 28 Sep 92 13:15:21 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <1992Sep24.090153.25082@bristol.ac.uk>, ccsw@bristol.ac.uk (EthaStorm) writes:
> In article <1992Sep24.053807.2965@cs.uow.edu.au> u9155406@cs.uow.edu.au (Gerardo Bentancor) writes:
>>G'day Folks,
>>	I wouldn't mind finding out what a good text for a) assembly 
>>programming on a 68000, and b) programming the Amiga (both C and assembly).
>>I have a few books, namely the Abacus series on C/Assembly programming. 
>>However I have found them to be a little buggy, and so not too reliable.
>>I also have the Amiga Hardware Reference Manual and the Autodocs (which are
>>excellent publications IMHO). Are there any others that are particularly 
>>good? And by the way, thanks to all who helped with my buggy assembly program,
>>I have learned a thing or two.
>>
>>						Gerardo.
>>
>>
>>u9155406@cs.uow.edu.au
> 
> 
> Hiho Gerardo.
> 
>    My advice is to look for the varied amounts of source code that is available
> on the InterNet. I started coding at the end of April, and I put about six
> hours a week into it (that's keyboard time!). I'm currently setting up my own
> views, viewports, doing 3D rotations and translations and getting the speech
> sysnthesiser to work.
> 
> There isn't a lot of assembly code on the InterNet, but there's an abundance of
> C code (which converts fairly easily to assembler).
> 
> As for books, I can recommend
> 
>    Mapping The Amiga by Rhett Anderson and Randy Thompson
> 
>    Published by Compute! Books
>    ISBN: 0-87455-195-1
> 
> There are mistakes in it (mainly of omission), but it explains most of the
> structures used by the Amiga, how to program Copperlists, the Blitter and
> other such goodies. There are a few full sources in there, in C, Assembler
> and Modula2. I found it a very good starting place for exploring. After buying
> this book, I threw out my ABacus book!!!
> 
>   Hope this helps,
> 
>     EthaStorm   *8)

and an even better source of C source is the PD C-Manual by the swedish coding 
group. the lastet version comes on 12 Disks and has source, executables and 
documentation. Older versions may be hanging around at an amiga ftp site near 
you.
Newsgroups: comp.sys.amiga.programmer