From: james@unlambda.com (James A. Crippen) Newsgroups: alt.sys.pdp10 Subject: Info for unzipping SIMH v2.7 Date: 24 Sep 2001 16:10:53 -0800 Lines: 21 Sender: james@kappa.unlambda.com Message-ID: NNTP-Posting-Host: 12.17.138.171 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1001376654 15596876 12.17.138.171 (16 [108589]) User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.dplanet.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!12.17.138.171!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6904 I tried unzipping SIMH v2.7 using Info-ZIP UnZip 5.42 of January 14, 2001 under Linux (glibc 2.1.3, gcc 2.95.3, kernel 2.4.7, etc). There appears to be a subtle gotcha with it in that if you don't tell it to autoconvert files then the sources are uncompilable due to some subtle problems with #define macros using \ to continue onto multiple lines. I started wondering if there was something funny going on when I noticed lots of complaints from GCC about stray '\'s in its input files. It took me a while to figure out what was wrong, but I found it. Anyway, if you find yourself having all sorts of spewage under a Unix when you try to compile SIMH, then this might be why. 'james -- James A. Crippen ,-./-. Anchorage, Alaska, Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W, Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, Y(F) = F(Y(F)) \_,-_/ Milky Way. ###### From: james@unlambda.com (James A. Crippen) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 24 Sep 2001 16:16:25 -0800 Lines: 25 Sender: james@kappa.unlambda.com Message-ID: References: NNTP-Posting-Host: 12.17.138.171 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1001376986 15596876 12.17.138.171 (16 [108589]) User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.dplanet.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!12.17.138.171!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6903 I, james@unlambda.com (James A. Crippen) wrote: > Anyway, if you find yourself having all sorts of spewage under a Unix > when you try to compile SIMH, then this might be why. After compiling I got a handful of warnings. Haven't looked at them, but here they are. I don't think Bob Supnik has a mailing list for his simulator, so I thought I'd post them here since I figure he probably reads this group. Other than the below warnings everything went fine. $ gcc -DUSE_INT64 -O2 -march=i686 -mcpu=i686 pdp10_*.c scp*.c sim_*.c -lm -o pdp10 pdp10_cpu.c: In function `sim_instr': pdp10_cpu.c:863: warning: comparison is always false due to limited range of data type pdp10_xtnd.c:169: warning: decimal constant is so large that it is unsigned pdp10_xtnd.c:177: warning: decimal constant is so large that it is unsigned 'james -- James A. Crippen ,-./-. Anchorage, Alaska, Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W, Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, Y(F) = F(Y(F)) \_,-_/ Milky Way. ###### Message-ID: <3BAFD9C0.8C471F81@srv.net> From: Kevin Handy X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 22 X-Complaints-To: abuse@usenetserver.com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly. NNTP-Posting-Date: Mon, 24 Sep 2001 21:13:04 EDT Organization: WebUseNet Corp. http://corp.webusenet.com - ReInventing the UseNet Date: Mon, 24 Sep 2001 19:11:28 -0600 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!Amsterdam.Infonet!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsmaster-01.atnet.at!atnet.at!newsrouter.chello.at!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!colt.net!newspump.monmouth.com!newspeer.monmouth.com!howland.erols.net!portc.blue.aol.com.MISMATCH!portc03.blue.aol.com!newsfeed.skycache.com.MISMATCH!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!e420r-sjo4.usenetserver.com!usenetserver.com!sjcpnn01.usenetserver.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6906 "James A. Crippen" wrote: > > I tried unzipping SIMH v2.7 using Info-ZIP UnZip 5.42 of January 14, > 2001 under Linux (glibc 2.1.3, gcc 2.95.3, kernel 2.4.7, etc). There > appears to be a subtle gotcha with it in that if you don't tell it to > autoconvert files then the sources are uncompilable due to some subtle > problems with #define macros using \ to continue onto multiple lines. On linux, you must use 'unzip -a', and then it seems to do the right thing, otherwise the files are loaded in MSDOS mode, which is a bad thing. Linux wants the files to have a single '\n' at the end of a line, and without the '-a' you get '\n\r'. This seems to upset the compiler in several places. > I started wondering if there was something funny going on when I > noticed lots of complaints from GCC about stray '\'s in its input > files. It took me a while to figure out what was wrong, but I found > it. > > Anyway, if you find yourself having all sorts of spewage under a Unix > when you try to compile SIMH, then this might be why. ###### From: james@unlambda.com (James A. Crippen) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 24 Sep 2001 20:58:48 -0800 Lines: 33 Sender: james@kappa.unlambda.com Message-ID: References: <3BAFD9C0.8C471F81@srv.net> NNTP-Posting-Host: 12.17.138.171 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1001393929 14959312 12.17.138.171 (16 [108589]) User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!fu-berlin.de!uni-berlin.de!12.17.138.171!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6902 Kevin Handy writes: > "James A. Crippen" wrote: > > > > I tried unzipping SIMH v2.7 using Info-ZIP UnZip 5.42 of January 14, > > 2001 under Linux (glibc 2.1.3, gcc 2.95.3, kernel 2.4.7, etc). There > > appears to be a subtle gotcha with it in that if you don't tell it to > > autoconvert files then the sources are uncompilable due to some subtle > > problems with #define macros using \ to continue onto multiple lines. > > On linux, you must use 'unzip -a', and then it seems to do the right > thing, otherwise the files are loaded in MSDOS mode, which is a bad > thing. Linux wants the files to have a single '\n' at the end of a > line, and without the '-a' you get '\n\r'. This seems to upset the > compiler in several places. Yup, that's exactly what I found out after looking at the output with a hex editor. I understand why GCC gets confused -- the \ only escapes the CR and not the LF, so the next line which should be a continuation of the macro is considered to be a lone C expression (which it greatly resembles). The cascade of errors is due to mismatched parens and missing semicolons. I hate C. Just give me Lisp. Real macro languages don't suffer from this. :-P 'james -- James A. Crippen ,-./-. Anchorage, Alaska, Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W, Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, Y(F) = F(Y(F)) \_,-_/ Milky Way. ###### From: "Harris Newman" Newsgroups: alt.sys.pdp10 References: <3BAFD9C0.8C471F81@srv.net> Subject: Re: Info for unzipping SIMH v2.7 Lines: 41 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <%F_r7.35$Kp2.191767@typhoon.austin.rr.com> Date: Tue, 25 Sep 2001 12:22:19 GMT NNTP-Posting-Host: 66.25.136.46 X-Complaints-To: abuse@rr.com X-Trace: typhoon.austin.rr.com 1001420539 66.25.136.46 (Tue, 25 Sep 2001 07:22:19 CDT) NNTP-Posting-Date: Tue, 25 Sep 2001 07:22:19 CDT Organization: Road Runner - Texas Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news2.euro.net!newspeer.clara.net!news.clara.net!feed2.onemain.com!feed1.onemain.com!feeder.qis.net!nntp.abs.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!cyclone.tampabay.rr.com!cyclone.austin.rr.com!typhoon.austin.rr.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6905 Wow, I finally got a clean compile! Maybe this should be mentioned in the docs. -HN "James A. Crippen" wrote in message news:m33d5bhnnb.fsf@kappa.unlambda.com... > Kevin Handy writes: > > > "James A. Crippen" wrote: > > > > > > I tried unzipping SIMH v2.7 using Info-ZIP UnZip 5.42 of January 14, > > > 2001 under Linux (glibc 2.1.3, gcc 2.95.3, kernel 2.4.7, etc). There > > > appears to be a subtle gotcha with it in that if you don't tell it to > > > autoconvert files then the sources are uncompilable due to some subtle > > > problems with #define macros using \ to continue onto multiple lines. > > > > On linux, you must use 'unzip -a', and then it seems to do the right > > thing, otherwise the files are loaded in MSDOS mode, which is a bad > > thing. Linux wants the files to have a single '\n' at the end of a > > line, and without the '-a' you get '\n\r'. This seems to upset the > > compiler in several places. > > Yup, that's exactly what I found out after looking at the output with > a hex editor. I understand why GCC gets confused -- the \ only > escapes the CR and not the LF, so the next line which should be a > continuation of the macro is considered to be a lone C expression > (which it greatly resembles). The cascade of errors is due to > mismatched parens and missing semicolons. > > I hate C. Just give me Lisp. Real macro languages don't suffer from > this. :-P > > 'james > > -- > James A. Crippen ,-./-. Anchorage, Alaska, > Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W, > Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, > Y(F) = F(Y(F)) \_,-_/ Milky Way. ###### From: Bob Supnik Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: Tue, 25 Sep 2001 12:13:25 -0400 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> References: X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Lines: 41 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!947738!news.imp.ch!sunqbc.risq.qc.ca!cyclone.bc.net!sjcppf01.usenetserver.com!usenetserver.com!sn-xit-04!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6907 The first warning is GCC being clever about optimizing. MOVNI expands to AC(ac) = MOVN (IM), where IM is ((d10) ea), followed by MOVNF (IM). MOVNF consists of two tests: a test against MAXNEG (2**35), and a test against zero. GCC is noticing that the first test will always fail, because the original operand, ea, is a 32b integer and can never be that big. Nice! I am less sure about the other two. This is an array of d10's, that is, of 64b integers. The numbers it is complaining about are 36b integers. In fact, they are unsigned 36b integers (ie, they are greater than 2**35), but they certainly fit within a 64b integer with plenty to spare. So I'm confused. /Bob On 24 Sep 2001 16:16:25 -0800, james@unlambda.com (James A. Crippen) wrote: >I, james@unlambda.com (James A. Crippen) wrote: > >> Anyway, if you find yourself having all sorts of spewage under a Unix >> when you try to compile SIMH, then this might be why. > >After compiling I got a handful of warnings. Haven't looked at them, >but here they are. I don't think Bob Supnik has a mailing list for >his simulator, so I thought I'd post them here since I figure he >probably reads this group. > >Other than the below warnings everything went fine. > >$ gcc -DUSE_INT64 -O2 -march=i686 -mcpu=i686 pdp10_*.c scp*.c sim_*.c -lm -o pdp10 >pdp10_cpu.c: In function `sim_instr': >pdp10_cpu.c:863: warning: comparison is always false due to limited range of data type >pdp10_xtnd.c:169: warning: decimal constant is so large that it is unsigned >pdp10_xtnd.c:177: warning: decimal constant is so large that it is unsigned > >'james ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 25 Sep 2001 17:49:04 GMT Organization: California Institute of Technology, Pasadena Lines: 23 Message-ID: <9oqg2g$3ms@gap.cco.caltech.edu> References: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> NNTP-Posting-Host: yak.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!205.231.236.10!newspeer.monmouth.com!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch alt.sys.pdp10:6908 Bob Supnik writes: >The first warning is GCC being clever about optimizing. >MOVNI expands to AC(ac) = MOVN (IM), where IM is ((d10) ea), >followed by MOVNF (IM). >MOVNF consists of two tests: a test against MAXNEG (2**35), and a test >against zero. GCC is noticing that the first test will always fail, >because the original operand, ea, is a 32b integer and can never be >that big. Nice! >I am less sure about the other two. This is an array of d10's, that >is, of 64b integers. The numbers it is complaining about are 36b >integers. In fact, they are unsigned 36b integers (ie, they are >greater than 2**35), but they certainly fit within a 64b integer with >plenty to spare. So I'm confused. I should probably download this and look at it before commenting, but if int is 32 bits, 64 bit long long constants should have an ll suffix. -- glen ###### From: james@unlambda.com (James A. Crippen) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 25 Sep 2001 10:17:55 -0800 Lines: 127 Sender: james@kappa.unlambda.com Message-ID: References: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> <9oqg2g$3ms@gap.cco.caltech.edu> NNTP-Posting-Host: 12.17.138.171 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1001441878 15618665 12.17.138.171 (16 [108589]) User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsmi-eu.news.garr.it!NewsITBone-GARR!fu-berlin.de!uni-berlin.de!12.17.138.171!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6909 gah@ugcs.caltech.edu (glen herrmannsfeldt) writes: > Bob Supnik writes: > > I should probably download this and look at it before commenting, > but if int is 32 bits, 64 bit long long constants should have an ll > suffix. You might be right. Lemme check. [...time passes...] Suffixing every single one of the constants in the array with ULL (unsigned long long) makes GCC shut up. The suffix LL is for signed long long. Now, I don't think that this applies for other compilers (eg, DEC Alpha Unix), but I'd bet that GCC is doing something unkind here. You may want to #ifdef this section for GCC or make some horrible macro to hide the suffix. For a good time, I ran gcc -Wall, which turns on most (not actually all) warnings. There are a lot of the following pdp10_defs.h:562: warning: `/*' within comment which are ignorable, since the standards allow that. Ignoring those warnings, here's the output (after the patch above with ULL). pdp10_cpu.c: In function `sim_instr': pdp10_cpu.c:639: warning: suggest parentheses around assignment used as truth value I think that GCC is being cute by warning us about this. It's saying that if(foo = bar()) should be better written as if((foo = bar())) analogous to if((foo = bar()) != NULL) and the like. I suppose that might be stylistically better, but I hardly think it matters. Changing it just to get GCC to shut up isn't necessarily a great idea. pdp10_cpu.c:651: warning: suggest parentheses around assignment used as truth value pdp10_cpu.c:863: warning: comparison is always false due to limited range of data type pdp10_cpu.c: In function `test_int': pdp10_cpu.c:1777: warning: suggest parentheses around assignment used as truth value In file included from pdp10_dz.c:30: dec_dz.h:125: warning: missing braces around initializer I describe this sort of warning below. dec_dz.h:125: warning: (near initialization for `dz_desc.ldsc') pdp10_ksio.c:79: warning: missing braces around initializer pdp10_ksio.c:79: warning: (near initialization for `ubmap[0]') pdp10_lp20.c: In function `lp20_svc': pdp10_lp20.c:344: warning: statement with no effect pdp10_lp20.c:328: warning: unused variable `err' pdp10_lp20.c: In function `lp20_adv': pdp10_lp20.c:479: warning: suggest parentheses around assignment used as truth value pdp10_lp20.c: In function `lp20_davfu': pdp10_lp20.c:500: warning: suggest parentheses around assignment used as truth value pdp10_mdfp.c: In function `fdv': pdp10_mdfp.c:432: warning: suggest parentheses around assignment used as truth value pdp10_rp.c: In function `rp_svc': pdp10_rp.c:826: warning: suggest parentheses around assignment used as truth value pdp10_xtnd.c:156: warning: missing braces around initializer pdp10_xtnd.c:156: warning: (near initialization for `pwrs10[0]') scp.c: In function `log_cmd': scp.c:734: warning: implicit declaration of function `nolog_cmd' I think this gets resolved at link time? But an extra declaration could help, since it would improve type checking, etc. scp.c: In function `fprint_stopped': scp.c:1271: warning: suggest parentheses around assignment used as truth value scp.c: In function `exdep_cmd': scp.c:1389: warning: suggest parentheses around assignment used as truth value scp.c: In function `get_search': scp.c:2040: warning: suggest parentheses around assignment used as truth value scp.c:2041: warning: suggest parentheses around assignment used as truth value scp.c:2046: warning: suggest parentheses around assignment used as truth value scp_tty.c: In function `sim_poll_kbd': scp_tty.c:661: warning: implicit declaration of function `read' scp_tty.c: In function `sim_putchar': scp_tty.c:671: warning: implicit declaration of function `write' The above two are resolved at link time. They come from . sim_tmxr.c: In function `tmxr_attach': sim_tmxr.c:309: warning: unused variable `sim_switches' In particular, the warnings like pdp10_xtnd.c:156: warning: missing braces around initializer pdp10_xtnd.c:156: warning: (near initialization for `pwrs10[0]') are because it wants you to do (using our friend pwrs10[][]) static const d10 pwrs10[23][2] = { {0ULL, 0ULL}, {0ULL, 1ULL}, {0ULL, 10ULL}, etc, instead of static const d10 pwrs10[23][2] = { 0ULL, 0ULL, 0ULL, 1ULL, 0ULL, 10ULL, . Ie, it wants the subarrays explicitly noted. I think that's why it mentions `pwrs10[0]' rather than `pwrs10[23][2]'. Maybe. In any case, I made that change and the warning went away, and I assume that it applies to all the other warnings of similar form. 'james -- James A. Crippen ,-./-. Anchorage, Alaska, Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W, Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, Y(F) = F(Y(F)) \_,-_/ Milky Way. ###### Message-ID: <3BB0D602.2D28C91B@srv.net> From: Kevin Handy X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 References: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> <9oqg2g$3ms@gap.cco.caltech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 57 X-Complaints-To: abuse@usenetserver.com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly. NNTP-Posting-Date: Tue, 25 Sep 2001 15:09:19 EDT Organization: WebUseNet Corp. http://corp.webusenet.com - ReInventing the UseNet Date: Tue, 25 Sep 2001 13:07:46 -0600 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!amsnews01.chello.com!newsgate.cistron.nl!news.tele.dk!small.news.tele.dk!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!e420r-sjo4.usenetserver.com!usenetserver.com!sjcpnn01.usenetserver.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6911 "James A. Crippen" wrote: ... > > You might be right. Lemme check. > > [...time passes...] > > Suffixing every single one of the constants in the array with ULL > (unsigned long long) makes GCC shut up. The suffix LL is for signed > long long. Now, I don't think that this applies for other compilers > (eg, DEC Alpha Unix), but I'd bet that GCC is doing something unkind > here. You may want to #ifdef this section for GCC or make some > horrible macro to hide the suffix. > > For a good time, I ran gcc -Wall, which turns on most (not actually > all) warnings. There are a lot of the following > > pdp10_defs.h:562: warning: `/*' within comment > > which are ignorable, since the standards allow that. Ignoring those > warnings, here's the output (after the patch above with ULL). > > pdp10_cpu.c: In function `sim_instr': > pdp10_cpu.c:639: warning: suggest parentheses around assignment used as truth value > > I think that GCC is being cute by warning us about this. It's saying > that > > if(foo = bar()) > > should be better written as > > if((foo = bar())) > > analogous to > > if((foo = bar()) != NULL) > > and the like. I suppose that might be stylistically better, but I > hardly think it matters. Changing it just to get GCC to shut up isn't > necessarily a great idea. This warning is there because many times someone will type if (a = b) when they really wanted if (a == b) It is usually more frequent that someone wanted a comparison in an 'if' statement and mistyped it, then wanted an assignment there and typed it right. The message is just there to catch this too common bug. The extra set a parentheses is just there so that you can tell gcc (and several other compilers) that you know what you are doing. ###### From: "Harris Newman" Newsgroups: alt.sys.pdp10 References: <3BAFD9C0.8C471F81@srv.net> <%F_r7.35$Kp2.191767@typhoon.austin.rr.com> Subject: Re: Info for unzipping SIMH v2.7 Lines: 20 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Tue, 25 Sep 2001 19:20:15 GMT NNTP-Posting-Host: 66.25.136.46 X-Complaints-To: abuse@rr.com X-Trace: typhoon.austin.rr.com 1001445615 66.25.136.46 (Tue, 25 Sep 2001 14:20:15 CDT) NNTP-Posting-Date: Tue, 25 Sep 2001 14:20:15 CDT Organization: Road Runner - Texas Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!cyclone.tampabay.rr.com!cyclone.austin.rr.com!typhoon.austin.rr.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6910 Well, I talked too soon. I was able to get a clean compile, and it does run. I can get the console to work just fine, but the telnet sessions just hang. This is shown on my site: Telnet newman.hn.org 2020 it comes up with Welcome to the pdp10 simulator, but nothing else happens (ctl-c, enter etc hit). Anyway, HELP!!!!!!!1 -HN "Harris Newman" wrote in message news:%F_r7.35$Kp2.191767@typhoon.austin.rr.com... > Wow, I finally got a clean compile! > Maybe this should be mentioned in the docs. > -HN > > ###### From: peter@taronga.com (Peter da Silva) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 25 Sep 2001 11:13:22 GMT Organization: TSS Inc. Lines: 18 Message-ID: <9oposi$i69$1@citadel.in.taronga.com> References: NNTP-Posting-Host: citadel.in.taronga.com X-Trace: citadel.in.taronga.com 1001416402 18633 10.0.0.43 (25 Sep 2001 11:13:22 GMT) X-Complaints-To: usenet@taronga.com NNTP-Posting-Date: 25 Sep 2001 11:13:22 GMT X-Newsreader: trn 4.0-test72 (19 April 1999) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!news.spies.com!news.kjsl.com!news.usenet2.org!citadel.in.taronga.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6928 In article , James A. Crippen wrote: >I tried unzipping SIMH v2.7 using Info-ZIP UnZip 5.42 of January 14, >2001 under Linux (glibc 2.1.3, gcc 2.95.3, kernel 2.4.7, etc). There >appears to be a subtle gotcha with it in that if you don't tell it to >autoconvert files then the sources are uncompilable due to some subtle >problems with #define macros using \ to continue onto multiple lines. There's nothing subtle about it. In UNIX, carriage return is just another character, so if you don't strip off the carriage returns what you end up doing is replacing "continue on next line" with "insert a literal carriage return". -- Rev. Peter da Silva, ULC. WWFD? "Be conservative in what you generate, and liberal in what you accept" -- Matthew 10:16 (l.trans) ###### From: Arthur Krewat Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Lines: 26 Message-ID: <3BB0E0C6.BA28D22F@bartek.dontspamme.net> References: <3BAFD9C0.8C471F81@srv.net> <%F_r7.35$Kp2.191767@typhoon.austin.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 i86pc) X-Accept-Language: en Date: Tue, 25 Sep 2001 19:57:44 GMT NNTP-Posting-Host: 24.186.100.134 X-Trace: news02.optonline.net 1001447864 24.186.100.134 (Tue, 25 Sep 2001 15:57:44 EDT) NNTP-Posting-Date: Tue, 25 Sep 2001 15:57:44 EDT Organization: Optimum Online Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!nf3.bellglobal.com!novia!novia!cyclone2.usenetserver.com!usenetserver.com!news01.optonline.net!news02.optonline.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6929 Harris Newman wrote: > > Well, I talked too soon. I was able to get a clean compile, and it does run. > I can get the console to work just fine, but the telnet sessions just hang. > This is shown on my site: > Telnet newman.hn.org 2020 > > it comes up with Welcome to the pdp10 simulator, but nothing else happens > (ctl-c, enter etc hit). > > Anyway, HELP!!!!!!!1 > -HN Are you running TOPS-10? I hit this too with 7.03, you need to setup TTY.INI to set the terminal speed, like this: .TYPE SYS:TTY.INI CTY: AUTOMATIC NO REMOTE ACCOUNT "SYSTEM" STOMP ACCOUNT "SYSTEM" TTY0-31: NAME NOTICE TEXT SPEED:9600 TYPE:VT100 if you are running TOPS-20, you probably have to do the same thing, but I have no idea how :) aak ###### From: Seth Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 25 Sep 2001 19:59:10 GMT Organization: Concentric Internet Services Lines: 30 Message-ID: <9oqnme$j5r@dispatch.concentric.net> References: <3BAFD9C0.8C471F81@srv.net> <%F_r7.35$Kp2.191767@typhoon.austin.rr.com> NNTP-Posting-Host: 205.158.23.172 User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (Linux/2.4.2 (i686)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!out.nntp.be!propagator-SanJose!news-in-sanjose!in.nntp.be!newspeer.cwnet.com!sjc1.nntp.concentric.net!newsfeed.concentric.net!global-news-master Xref: chonsp.franklin.ch alt.sys.pdp10:6933 Harris Newman wrote: > Well, I talked too soon. I was able to get a clean compile, and it does run. > I can get the console to work just fine, but the telnet sessions just hang. > This is shown on my site: > Telnet newman.hn.org 2020 > it comes up with Welcome to the pdp10 simulator, but nothing else happens > (ctl-c, enter etc hit). > Anyway, HELP!!!!!!!1 No, that's fine :) Nothing will appear until you enable the OS to talk to your virtual DZ11 ttys. I had the same problem, I puzzled over it for quite some time until finally finding an answer buried on the web or Usenet somewhere. Assuming that you're running TOPS-10 7.03, you'll need to edit SYS:TTY.INI and add the line: TTY0-31: NAME NOTICE TEXT SPEED:9600 TYPE:VT100 This enables TTY0 through TTY31 to listen at 9600 baud with a VT100 terminal type. Good luck! > -HN -Seth ###### From: "Zane H. Healy" Subject: Re: Info for unzipping SIMH v2.7 Newsgroups: alt.sys.pdp10 References: <3BAFD9C0.8C471F81@srv.net> <%F_r7.35$Kp2.191767@typhoon.austin.rr.com> <3BB0E0C6.BA28D22F@bartek.dontspamme.net> Organization: Aracnet User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.19 (i686)) Lines: 26 Message-ID: <_e6s7.1121$7k.20964@atlpnn01.usenetserver.com> X-Complaints-To: abuse@usenetserver.com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly. NNTP-Posting-Date: Tue, 25 Sep 2001 16:59:38 EDT Date: Tue, 25 Sep 2001 20:59:38 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!64.152.100.70!sjcppf01.usenetserver.com!e420r-sjo4.usenetserver.com!usenetserver.com!atlpnn01.usenetserver.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6938 Arthur Krewat wrote: > if you are running TOPS-20, you probably have to do the same > thing, but I have no idea how :) Maybe something like this: @TYPE PS:4-1-CONFIG.CMD TERMINAL 1 SPEED 9600 TERMINAL 2 SPEED 9600 TERMINAL 3 SPEED 9600 TERMINAL 4 SPEED 9600 TERMINAL 5 SPEED 9600 TERMINAL 6 SPEED 9600 That's how I got my lines set to 9600 finally. So far I'm only using TOPS-20 under simh 2.7, and I've got it running on SUSE Linux 7.2. In fact I was able to connect to it before getting the lines setup properly as shown above. I need to find someplace to stuff the bare system board, PS, and HD before I try moving my TOPS-10 setup to the system :^) I'm just wondering how hard it would be to build a scale model of a KS10 to stuff the pieces into. Either that or if I could stuff it into a VT100 (I think I might be able t). Zane ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: alt.sys.pdp10 Subject: Re: Info for unzipping SIMH v2.7 Date: 25 Sep 2001 23:18:18 GMT Organization: California Institute of Technology, Pasadena Lines: 29 Message-ID: <9or3bq$fj2@gap.cco.caltech.edu> References: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> <9oqg2g$3ms@gap.cco.caltech.edu> NNTP-Posting-Host: yak.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!newspeer.monmouth.com!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch alt.sys.pdp10:6923 james@unlambda.com (James A. Crippen) writes: >gah@ugcs.caltech.edu (glen herrmannsfeldt) writes: >> Bob Supnik writes: >> >> I should probably download this and look at it before commenting, >> but if int is 32 bits, 64 bit long long constants should have an ll >> suffix. >You might be right. Lemme check. >[...time passes...] >Suffixing every single one of the constants in the array with ULL >(unsigned long long) makes GCC shut up. The suffix LL is for signed >long long. Now, I don't think that this applies for other compilers >(eg, DEC Alpha Unix), but I'd bet that GCC is doing something unkind >here. You may want to #ifdef this section for GCC or make some >horrible macro to hide the suffix. Yes, ULL for unsigned. (I don't think you said that before.) DEC Alpha Unix has always had 64 bit long, and may not have long long. gcc has traditionally had 32 bit long, and may not have wanted to change that. There is a C rule that says that a constant too big to be an int is automatically a long. There probably isn't a similar rule for long long. -- glen ###### From: "David Thompson" Newsgroups: alt.sys.pdp10 References: <3m31rtossgdaf23skrj1jb8pu0pmud6ahe@4ax.com> <9oqg2g$3ms@gap.cco.caltech.edu> <9or3bq$fj2@gap.cco.caltech.edu> Subject: Re: Info for unzipping SIMH v2.7 Lines: 42 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Mon, 01 Oct 2001 04:50:23 GMT NNTP-Posting-Host: 12.89.135.12 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1001911823 12.89.135.12 (Mon, 01 Oct 2001 04:50:23 GMT) NNTP-Posting-Date: Mon, 01 Oct 2001 04:50:23 GMT Organization: AT&T Worldnet Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fr.clara.net!heighliner.fr.clara.net!feed2.onemain.com!feed1.onemain.com!novia!novia!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn3feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:6959 glen herrmannsfeldt wrote : > james@unlambda.com (James A. Crippen) writes: > >gah@ugcs.caltech.edu (glen herrmannsfeldt) writes: > > >> Bob Supnik writes: > >> > >> I should probably download this and look at it before commenting, > >> but if int is 32 bits, 64 bit long long constants should have an ll > >> suffix. ... > >Suffixing every single one of the constants in the array with ULL > >(unsigned long long) makes GCC shut up. The suffix LL is for signed > >long long. ... d10 is t_int64 is (signed) long long. But these values are (well) within the minimum common range of LL and ULL so either works fine. > .... There is a C rule that says that a constant > too big to be an int is automatically a long. There probably isn't > a similar rule for long long. > There is in "C99" (the newly revised standard, ISO/IEC 9899:1999) 6.4.4.1, and decimal without U no longer ends at unsigned longest. But the gcc versions most folks are probably using implemented C90 with "long long" as an _extension_, which means they had to go to/via unsigned long=32 to support the old rules (C90 6.1.3.2), and I think even the newer versions which implement much but not all of C99 do so only by a nondefault option. Of course in a conversion context either unsigned-32 (int or long) or signed-64 (long long) produces the right result. Another possibility is to use octal which without U goes through both signed and unsigned at all sizes, and produces no warning on the gcc versions I have conveniently available. (Hex has the same property, but hex in -10 simulator code would be heresy.) -- - David.Thompson 1 now at worldnet.att.net