kent@opus.austin.ibm.com (Kent Malave') (08/03/90)
In article <61875@bu.edu.bu.edu>, jdh@bu-pub.bu.edu (Jason Heirtzler) writes: > > How do you change the console to be an HFT, rather than a serial port? It's > straight forward if you're reinstalling AIX from scratch (just make sure the > serial port isn't plugged in when you run the install) but i don't want to > go through that, just to change it. > To reassign the console, you can use the smit command. Simply type smit system and select "Assign the Console" menu item. Now just assign it to /dev/hft/0 and all will be changed on your next reboot. > Also, it looks like alloca isn't in libbsd.a or libc.a. Was this just an > oversight in this release? If this is true, is there someone who can give > me a copy (hello IBM?) > You may want to look in /usr/lpp/bos. In this directory there are to very good articles on AIX and BSD differences in system administration (file bsdadm) and porting of code (file bsdport). Also you may want to take the time to read the README file that resides in this directory as well. Also bsdport and bsdadm are supplied in t/nroff format, see the README file. I hope this helps. I personally have found the bsdport document a lot of help. > RS6000, model 320, AIX 9021 > > ------------------------------------------------------------------- > Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu > Information Technology Boston University ..!bu.edu!bu-pub!jdh =============================================================================== Kent Malave' ...uunet!cs.utexas.edu!ibmchs!auschs!opus.austin.ibm.com!kent Disclaimer: This is no one's opinion. (Not even mine!) ===============================================================================
swise@elric.austin.ibm.com (The Diet Coke Guy) (08/03/90)
In article <61875@bu.edu.bu.edu> you write: >How do you change the console to be an HFT, rather than a serial port? It's >straight forward if you're reinstalling AIX from scratch (just make sure the >serial port isn't plugged in when you run the install) but i don't want to >go through that, just to change it. Using SMIT, select the "System Environments & Processes" menu, then select, "Assign the Console." You can then change the console to be /dev/hft. You can alternatively use the chcons command. > >Also, it looks like alloca isn't in libbsd.a or libc.a. Was this just an >oversight in this release? If this is true, is there someone who can give >me a copy (hello IBM?) I couldn't find alloca in the libc/libbsd source either...hmmmm... We do NOT have alloca in 3.1 AIX, but you can use it by putting the following line in your C source: #pragma alloca This came from a file called bsdport in /usr/lpp/bos. It has many helpfull hints for porting BSD apps to AIX 3.1. It also describes how to set up a bsd compile stanza in /etc/xlc.cfg that work wonders on BSD apps!! ******** Steve Wise - IBM Advanced Workstation Division - Austin, Tx. swise@elric.austin.ibm.com AUSVMQ(SWISE) uunet.UU.NET!cs.utexas.edu!ibmchs!auschs!elric.austin.ibm.com!swise
jsalter@slo.paloalto.ibm.com (08/04/90)
In article <61875@bu.edu.bu.edu> jdh@bu-pub.bu.edu (Jason Heirtzler) writes: >How do you change the console to be an HFT, rather than a serial port? It's >straight forward if you're reinstalling AIX from scratch (just make sure the >serial port isn't plugged in when you run the install) but i don't want to >go through that, just to change it. Have you looked at the 'chcons' or 'chdisp' commands and their relatives? >Also, it looks like alloca isn't in libbsd.a or libc.a. Was this just an >oversight in this release? If this is true, is there someone who can give >me a copy (hello IBM?) One of the mysteries of AIXv3.1 is the following: To access the alloca() function, you need to add the following line to the beginning of your SOURCE code: #pragma alloca This will make the alloca() routine available for use. I you don't have InfoExplorer/Documentation, get it. It has all this information available, and you can even do searches for the various strings. >Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu >Information Technology Boston University ..!bu.edu!bu-pub!jdh jim/jsalter IBM AWD, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: ibmsupt!jsalter@uunet.uu.net UUCP: ..!uunet!ibmsupt!jsalter "I'm going to win. I always do." George Steinbrenner, on ESPN.
dcm@toysrus.uucp (dcm) (08/05/90)
In article <1990Aug3.170532.11038@ibmpa> jsalter@slo.UUCP (James Salter) writes: > >One of the mysteries of AIXv3.1 is the following: > > To access the alloca() function, you need to add the following > line to the beginning of your SOURCE code: > > #pragma alloca > > This will make the alloca() routine available for use. Jim, you sound like this is cruel & unusual. I personally think if you use alloca, you get what you deserve (unportable code). But we should discourage it. And the compiler usually needs to help anyway... I don't consider #pragma alloca cruel or unusual at all. Let's make people think about it before they use it (heck, C went ~15 years without it anyway). Craig "we don't need no stinking fsck on our filesystem" "jfs = jeff's filesystem" -------- Craig Miller, contractor @ IBM AWD, Austin UUCP: ..!uunet!cs.utexas.edu!ibmaus!auschs!toysrus.austin.ibm.com!dcm "Bo knows uucp."
jsalter@slo.paloalto.ibm.com (08/05/90)
In article <3048@awdprime.UUCP> dcm@austin.ibm.com (Craig Miller) writes: >In article <1990Aug3.170532.11038@ibmpa> jsalter@slo.UUCP (James Salter) writes: >>One of the mysteries of AIXv3.1 is the following: >> To access the alloca() function, you need to add the following >> line to the beginning of your SOURCE code: >> >> #pragma alloca >> >> This will make the alloca() routine available for use. > > Jim, you sound like this is cruel & unusual. I personally think > if you use alloca, you get what you deserve (unportable code). I didn't mean to imply that it was cruel & unusual. The man page, however, is not clear as to how to use the alloca() subroutine. Thus, many people find compiler errors, with respect to alloca(), mysterious. Even we had problems finding it when we first looked for it. > Craig Miller, contractor @ IBM AWD, Austin > UUCP: ..!uunet!cs.utexas.edu!ibmaus!auschs!toysrus.austin.ibm.com!dcm jim/jsalter IBM AWD, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: ibmsupt!jsalter@uunet.uu.net UUCP: ..!uunet!ibmsupt!jsalter "I'm going to win. I always do." George Steinbrenner, on ESPN.
guy@auspex.auspex.com (Guy Harris) (08/06/90)
> But we should discourage it. And the compiler usually needs to > help anyway... I don't consider #pragma alloca cruel or unusual > at all. Let's make people think about it before they use it > (heck, C went ~15 years without it anyway). Yes, but Sun (for SPARC) and, I think, MIPS hide the help they give the compiler (a #define, rather than a #pragma, in Sun's case) in an include file <alloca.h>; if they both do so, it might be wise for IBM to get with the program, the fact that "alloca()" is non-portable and probably shouldn't be used nonwithstanding....
tif@doorstop.austin.ibm.com (Paul Chamberlain) (08/06/90)
regarding the use of alloca(), Craig Miller writes > But we should discourage it. [...] > Let's make people think about it before they use it [...] Remember "Market Driven," not "Driven Market." Paul Chamberlain | I do NOT represent IBM tif@doorstop, sc30661@ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
madd@world.std.com (jim frost) (08/07/90)
kent@opus.austin.ibm.com (Kent Malave') writes: >> Also, it looks like alloca isn't in libbsd.a or libc.a. Was this just an >> oversight in this release? If this is true, is there someone who can give >> me a copy (hello IBM?) >> > You may want to look in /usr/lpp/bos. In this directory there are > to very good articles on AIX and BSD differences in system administration > (file bsdadm) and porting of code (file bsdport). The bsdport file is pretty good, if you're porting bsd code I recommend it. There are still some gotchas, though. First gotcha is you need to include #pragma alloca to get alloca. It's pretty hard to build a function that does alloca on a lot of machines (the rios is one of them) so it's done inline. It also uses an extra register because it keeps both a stack pointer (r1) and a frame pointer (r31) so you get moderately less efficient code. Second gotcha is that if you're using /lib/cpp as recommended in bsdport, #pragma alloca will cause it to internal error. You can do this in one line: % cat > foo.c #pragma alloca ^D % cc -B/lib/ foo.c # bsdcc from bsdport does this [some number] Internal error -- please contact your IBM representative. I might be wrong about the -B flag, I don't have the documentation handy and it might be some other letter. The internal cpp doesn't internal error. It does, however, barf on at-signs (@) which is hardly nice behavior. On the up-side, compatibility with BSD code seems very high. About the only problem I had on the stuff I have ported was that sigcontext (mstsave or whatever on the rios) is radically different and that compiling in BSD mode is pretty slow. Happy hacking, jim frost saber software jimf@saber.com
madd@world.std.com (jim frost) (08/07/90)
guy@auspex.auspex.com (Guy Harris) writes: >Yes, but Sun (for SPARC) and, I think, MIPS hide the help they give the >compiler (a #define, rather than a #pragma, in Sun's case) in an include >file <alloca.h>; On the MIPS architecture alloca is a bitch to do -- a stack frame *cannot* change size. The DECstation doesn't even have a real alloca, but instead uses malloc. Calls to alloca with a zero argument free everything allocated with alloca. I have a similar function that I sometimes use on machines that have a broken alloca. I haven't looked at the MIPS stuff close enough to tell if they do the same as DEC but I wouldn't be at all surprised. It would have been nice for IBM to have hidden the #pragma and it would also have been nice for them to allow it at any place outside of a function. Unfortunately they didn't, too bad, but in my experience this won't be the worst problem you come across when porting code written by people who think alloca is portable. Happy hacking, jim frost saber software jimf@saber.com