| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3838.1 | | WJG::GUINEAU | | Mon Jun 11 1990 16:04 | 4 |
| And here's DICE (Dillon's Integrated C Environment)
wjg::amiga:dice-202.zoo
|
| 3838.2 | UUCP disk 2 missing! | WJG::GUINEAU | | Tue Jun 12 1990 09:31 | 7 |
| Sorry Folks,
It was brought to my attention that I kinda missed disk 2 of UUCP 1.06D.
Waiting for BITFTP now...
john
|
| 3838.3 | uucp 1.06D | WJG::GUINEAU | | Thu Jun 14 1990 00:29 | 13 |
|
As promised, here is UUCP 1.06D from Matt Dillon. It's actually 3 disks!
wjg::amiga:uucp_106d_1.zoo
wjg::amiga:uucp_106d_2.zoo
wjg::amiga:uucp_106d_3.zoo
Has anyone tried Matt's DICE C compiler yet?
(where *does* he get the time to write this stuff?!?!?)
john
|
| 3838.4 | Works as advertised. | AYOV28::ATHOMSON | C'mon, git aff! /The Kelty Clippie | Fri Jun 22 1990 11:46 | 25 |
|
re: .-1
�Has anyone tried Matt's DICE C compiler yet?
I downloaded it yesterday and put in some time 'playing' with it last
night, from what I've tried it certainly seems to work as advertised.
I compiled some of the example programs from the C-tutorial disks from
the fish disk, and they all compiled sucessfully unmodified except those
that used the 'chip' qualifier. The resulting file sizes were
comparable with the executables supplied which were compiled under
Lattice 5.4
I also compiled a program which I had lying around (I think it came
from the Designer Disk Set [Amiga World disks ??? - can't remember])
which gave a benchmark measurement in Dhrystones. The original
(compiled under Lattice V3.03) from the designer disk rated my machine
at 471 dhrystones (14Mhz CMI processor accellerator) using the version
which uses register variables. After compiling the source with DICE it
rated my machine at 833 Dhrystones !! I know that comparing it with
Lattice 3.03 probably isn't particularly valid but it certainly
impressed me !
Alan T.
|
| 3838.5 | No chip memory switch in DICE? | RGB::ROSE | | Tue Jun 26 1990 09:58 | 10 |
| I have been playing with DICE. It does not appear to have a switch
to put the code in chip memory. The DAS documentation mentions that the
SECTION command permits hunk flags for chip memory. It stops short
of telling you how to do it. There appears to be no switch in DCC to
do it. Am I missing something?
If I do an AllocMem() to chip memory and copy an image there, do I
have to use the large data model to access it?
Otherwise, DICE seems to work pretty well.
|
| 3838.6 | Ok whats the 1990.lzh do.... | CSC32::A_ANDERSON | Had Screw Driver did Travel | Fri Jun 29 1990 19:35 | 6 |
| Any one figured out what 1990.lzh does. I tried run, execute, edit,
type, display, play, nothing..... It unpacks ok tho..
Alan
Curiosity killed the noter...
|
| 3838.7 | 1990... not worth the DL time | RLAV::WEGER | NJCD SWS, Piscataway NJ. 323-4468 | Fri Jun 29 1990 21:22 | 6 |
| It's a pretty crummy demo IMHO. It runs on my 1 meg 500 if I abort my
startup right away and 'run' it from the CLI.
Maybe it does something more but I just havn't figured it out.
-Bruce
|