ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/12/90)
Category 6, Topic 52 Message 1 Mon Dec 10, 1990 R.GIBBS3 [darren] at 18:51 PST I'm a graduate student in electronic music and am interested in working in forth on the nextcubes. I've been coding in forth and HMSL (an object oriented forth based experimental music language developed here at Mills College) for about 2 years. I'm now extremely sick of the Mac and wanted to getget to know mach/unix by porting HMSL over to the cubes as part of my masters project. Unfortunately I've found out that next doesn't support a 68k assembler as part of their development tools. I'm kind of confused about what to do next (pun only slightly intended). Does anyone know of an existing forth for the cubes. Have any advice about forth in a unix-like environment. Just wan't to see what help I can find and get to know the folks here... darren ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
shri@ncst.ernet.in (H.Shrikumar) (12/18/90)
In article <2095.UUL1.3#5129@willett.pgh.pa.us> from the ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >Category 6, Topic 52 >Message 1 Mon Dec 10, 1990 >R.GIBBS3 [darren] at 18:51 PST > >I'm a graduate student in electronic music and am interested in working in >forth on the nextcubes. I've been coding in forth and HMSL (an object >oriented forth based experimental music language developed here at Mills >College) for about 2 years. I'm now extremely sick of the Mac and wanted to .. and ... >getget to know mach/unix by porting HMSL over to the cubes as part of my >masters project. Unfortunately I've found out that next doesn't support a 68k >assembler as part of their development tools. I'm kind of confused about what >to do next (pun only slightly intended). Does anyone know of an existing >forth for the cubes. Have any advice about forth in a unix-like environment. >Just wan't to see what help I can find and get to know the folks here... >darren Hi Darren, The net has gone thru a debate not long ago which concluded that those you wrote FORTHs in C are heretics; I shall very coldly ignore that bit of religion :-) One *big* difference in working with the Next is that you are in a UNIX (like) enviroment - there is a "real OS" in there, unlike Forth on a raw hardware, or Forth in Mess-DOS etc. (I am not too sure about FORTH in Macs, but I guess they too have a fairly free use of the machine resource, memory , timer and all, am I right ?) A "real OS" comes with a pre-packaged "real philosophy" and you just have to understand it and be true to it. Under UNIX, you lose the following from the word go: 1. Real time, you program will be swapped in at the discretion of the OS 2. Twiddiling memory, no way. You are trapped in a segment of memory pages that are yours and all else PEEKing will have to be via system calls. 3. All I/O etc. are done on your behalf by the OS which will share devices with the other users. 4. Portability takes a different abstract meaning, you are portable as long as you stick to a specification, in this case POSIX or similar. *irrespective* of whether there is a 68K or a SPARC or a CRAY or a 6502 underneath it. > Unfortunately I've found out that next doesn't support a 68k assembler. Dont even really look for one, unless you want to throw away all Systems software and write to bare Machine; in which case there is no commitment from Next to be compatible in future versions of hardware. It is OK to write a few routines, and only those which deal only with your internal data structures in assembler, otherwise you must use whatever interface libraries are provided, eg. the C system call library. One way to do it is using C-booted Forths such as TILE from Mikael Patel. Lets take the above points one by one ... 1. Real time lost ... there are ways; it is surely not a lost cause. My work involves real-time, and I live in UNIX. We'll come to this last. 2. Twiddling memory, eg writing to hardware ports, serial ports, interrupts and interrupt controllers etc. are strictly out. Only way out is to write device drivers, they are tough to write, you'll need support from the Next people to do it, and saying more about UNIX device drivers is best done in comp.unix.{wizards,internals} 3. I/O use only the standard UNIX I/O system calls to do them. Stick to Posix and you have ported not only to the next but to thousands of UNIX platforms. 4. Portability ... is automatic, when you stick to the philosophy. TILE gives you a very comfortable programming environment. With a reasonably fast Forth, you get a good emacs interface too. Each primitive in FORTH is coded as a C routine in TILE. (consider C as an abstraction of assembly, as something that gets compiled into the right kind of assembly, so is a sort of universal assembly language.) All other FORTH words can be written in FORTH. Some tips ... leave aside Forth for a week or so, and read up books such a Kernighan and Pike, or Rochkind (both Prentice-Hall). Understand what a multi-user OS is like inside, without a FORTH prejudice. Get TILE running and play with it. Add a few primitives, such as a word to get some sound out of the DSP sound chips (or whatever, I have not worked with a Next, so someone who has can fill in the detail) as a C routine, and call it from FORTH in a FORTH program, in a loop etc. You are now ready to port HMSL into TILE. Now for the deferred point ... Real Time. In vanilla UNIX, the user processes are all in a virtual time world of their own. Sure you can look at the wall clock time, but you cant tell the OS that you have to do this execution at this time. Before someone screams, sure you can do that, but not with arbitrarily small granularity, perhaps not better than a second. In any case dont bet on any better. A Next has lot of raw MIPS, so if you have a very lightly loaded NEXT, then surely you can busy loop looking at the wall-clock, wating for the correct time slot. But this is forgivable only on a lightly loaded workstation, not on a timeshared central machine on Campus. I think HMSL does need a fairly accurate clock, so you may have no other choice. The elegant design of course is to split the time-critical part into a device-driver (perhaps you can look at devmidi, available at ucsd.edu by ftp), and the rest into a user program. -- shrikumar ( shri@ncst.in )