├── INSTALL
├── Inventory
├── Makefile
├── README.md
├── Windows
├── ReadMe.txt
├── stdafx.cpp
├── stdafx.h
├── targetver.h
├── ttm.sdf
├── ttm.sln
├── ttm.suo
├── ttm.vcxproj
├── ttm.vcxproj.filters
└── ttm.vcxproj.user
├── build.xml
├── src
└── main
│ └── java
│ └── ucar
│ └── ttm
│ └── TTM.java
├── test.baseline
├── test.rs
├── test.ttm
├── ttm.c
├── ttm.html
├── ttm.py
├── ttm_batch_processing_pr_08.pdf
├── ttm_interpretive_language_pr_07.docx
└── ttm_interpretive_language_pr_07.pdf
/INSTALL:
--------------------------------------------------------------------------------
1 | There are three versions of the ttm interpreter. One is
2 | written in C, one is written Java, and one is written in
3 | Python.
4 |
5 | -------------
6 | C Interpreter
7 | -------------
8 | The C interpreter is deliberately contained in a single,
9 | self contained C file: ttm.c. A Makefile exists to create
10 | ttm.ex At the beginning of ttm.c, there are some directives
11 | that control features of the interpreter. Currently the
12 | only directives are as follows:
13 | 1. #define HAVE_MEMMOVE - define this if your C compiler/library
14 | supports the memmove() function, undefine otherwise.
15 |
16 | You may also need to change the following lines in the Makefile.
17 | 1. CC - to specify the C compiler
18 | 2. CCWARN - compile time checks
19 | 3. CCDEBUG - to set the optimization and debug levels
20 |
21 | Otherwise, compiling is as simple as "${CC} -o ttm ttmc."
22 | where ${CC} is your local C compiler.
23 |
24 | Windows Support
25 | ---------------
26 | A Windows solutions file is defined in the directory
27 | "Windows". It currently will build and run under Visual
28 | Studio C++ 2010, but the resulting ttm.exe fails when run
29 | standalone. Any help in fixing this would be Appreciated.
30 |
31 | -------------
32 | Java Interpreter
33 | -------------
34 | The Java implementation is contained in the single file
35 | src/main/java/ucar/ttm/TTM.java. An ant build.xml file
36 | exists to compile it. The Java version is noticably slower
37 | than the C version.
38 |
39 | -------------
40 | Python Interpreter
41 | -------------
42 | The python implementation is contained in the single file
43 | ttm.py. It currently used python version 2.6.7; it has not
44 | been tested against python 3.0 yet. It does not need to be
45 | compiled per-se, just executed. It can be tested using the
46 | command "make pycheck".
47 |
48 |
49 |
--------------------------------------------------------------------------------
/Inventory:
--------------------------------------------------------------------------------
1 | Inventory
2 | README.md
3 | INSTALL
4 | Makefile
5 | build.xml
6 | test.baseline
7 | test.rs
8 | test.ttm
9 | ttm.c
10 | ttm.html
11 | ttm.py
12 | ttm_batch_processing_pr_08.pdf
13 | ttm_interpretive_language_pr_07.docx
14 | ttm_interpretive_language_pr_07.pdf
15 | src/main/java/ucar/ttm/TTM.java
16 | Windows/Debug
17 | Windows/ipch
18 | Windows/ReadMe.txt
19 | Windows/stdafx.cpp
20 | Windows/stdafx.h
21 | Windows/targetver.h
22 | Windows/ttm.sdf
23 | Windows/ttm.sln
24 | Windows/ttm.suo
25 | Windows/ttm.vcxproj
26 | Windows/ttm.vcxproj.filters
27 | Windows/ttm.vcxproj.user
28 |
--------------------------------------------------------------------------------
/Makefile:
--------------------------------------------------------------------------------
1 | EXPORT=f:/git/export
2 | .PHONEY: check
3 |
4 | CC=gcc
5 | CCWARN=-Wsign-compare -Wall -Wdeclaration-after-statement
6 | CCDEBUG=-g -O0
7 |
8 | all: ttm.exe
9 |
10 | clean::
11 | rm -f ttm.exe ttm ttm.txt test.output tmp
12 |
13 | ttm.exe: ttm.c
14 | ${CC} ${CCWARN} ${CCDEBUG} -o ttm ttm.c
15 |
16 | ttm.txt::
17 | rm -f ttm.txt
18 | gcc -E -Wall -Wdeclaration-after-statement ttm.c > ttm.txt
19 |
20 | TESTPROG=-p test.ttm
21 | TESTARGS=a b c
22 | TESTRFLAG=-f test.rs
23 | TESTCMD=./ttm ${TESTPROG} ${TESTRFLAG} ${TESTARGS}
24 | PYCMD=python ttm.py -dT ${TESTPROG} ${TESTRFLAG} ${TESTARGS}
25 |
26 | check:: ttm.exe
27 | rm -f ./test.output
28 | ${TESTCMD} >& ./test.output
29 | diff -w ./test.baseline ./test.output
30 |
31 | pycheck:: ttm.py
32 | rm -f ./test.output
33 | ${PYCMD} >& ./test.output
34 | diff -w ./test.baseline ./test.output
35 |
36 | git::
37 | ${SH} ./git.sh
38 |
39 | install::
40 | rm -fr ${EXPORT}/ttm/*
41 | cp -fr ./git/ttm ${EXPORT}
42 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Project Description
2 | The goal of the **ttm** project is to provide
3 | a reference implementation for the TTM programming language.
4 |
5 | TTM is a form of macro processor similar to TRAC, GAP, and GPM.
6 |
7 | # Syntax and Semantics
8 | It is assumed that TTM is given a text file containing some combination
9 | of ordinary text and TTM function calls (i.e. invocations).
10 | The text is scanned character by character. Any ordinary text is passed
11 | to the output unchanged (except when escaped).
12 | If a TTM function is encountered, it is collected and executed.
13 | The general form of a TTM function call looks like this.
14 |
15 | #<functionname;arg1;arg2;...;argn>
16 |
17 | where the functionname and the arguments are arbitrary character strings
18 | not characters of significance: '#', '<', '>', and ';'.
19 | The function is invoked with the specified arguments and the resulting
20 | text is inserted into the original text in place of the function call.
21 | If the function call was prefixed by a single '#' character, then scanning
22 | will resume just ''before'' the inserted text from the function call. If the
23 | function call was prefixed by two '#' characters, then scanning
24 | resumes just ''after'' the inserted text.
25 |
26 | During the collection of a function call, additional function calls
27 | may be encountered, for example, this.
28 |
TTM (or ttm)
22 | is a string oriented, general purpose macro processing
23 | developed in 1968 by Steven H. Caine and E. Kent Gordon at
24 | the California Institute of Technology.
25 |
26 | The following description is taken from the original TTM reference manual[1].
27 | TTM Is a recursive, interpretive language designed primarily
28 | for string manipulation, text editing, macro definition and
29 | expansion, and other applications generally classified as
30 | systems programming. It is derived, primarily, from
31 | GAP [3] and GPM [4].
32 |
33 |
OPTIONS
34 | Except where indicated, all flags may be repeated multiple times.
35 |
36 |
-d string
37 |
38 | Set a variety of debug options as encoded in the string.
39 | Currently, the following debug flags are defined.
40 |
48 | Scan the string and execute any macro invocations. Any output
49 | left after execution is discarded.
50 |
51 |
-p programfile
52 |
53 | Read and scan the contents of the program file.
54 | Any output is discarded.
55 |
56 |
-i
57 |
58 | After executing any -e or -p options,
59 | enter the read-eval loop to execute commands interactively.
60 | If not specified, then the interpreter will terminate execution
61 | after all other command line arguments have been processed.
62 |
63 |
-f inputfile
64 |
65 | Specify the input file. This file will be scanned
66 | and any resulting output will be sent to
67 | the -o file, if specified, otherwise to standard output.
68 | Note that this is not the same as the file
69 | specified by the -r flag.
70 |
71 |
-o file
72 |
73 | Send all output to the specified file. If not specified, then
74 | output is sent to standard output.
75 |
76 |
-r rsfile
77 |
78 | Specify a file from which #<rs> will read its input.
79 | If not specified, standard input is assumed.
80 | Note that this is not the same as the file
81 | specified by the -f flag.
82 |
83 |
-V
84 |
85 | Output the version number of ttm and then exit.
86 |
-q
87 |
88 | Suppress the output remaining after
89 | scanning the -f file.
90 |
91 |
-X tag=value
92 |
93 | Set a ttm interpreter resource limit.
94 | The tag is a single character indicating what resource
95 | to set, and the value is the value to assign to that resource.
96 | The legal tag characters are as follows:
97 |
98 |
Tag
Resource
Value
Description
99 |
b
Buffersize
integer>0
100 | Set the internal buffer size. The default is 2^20 characters.
101 | The suffix m|M is allowed to indicate multiplying by 2^20.
102 | The suffix k|K is allowed to indicate multiplying by 2^10;
103 |
s
Stacksize
integer>0
104 | Set the internal stack size. The default provides for a maximum
105 | depth of 64. It is a good idea to keep this number small
106 | so that runaway recursion can be detected quickly.
107 |
x
Executions
integer>0
108 | Limit the number of executions. The default is 2^20.
109 | The purpose is to catch tail recursive executions that
110 | do not eat up space.
111 |
112 |
113 |
--
114 |
115 | Signal the end of options and disable further option
116 | processing. Anything after the -- is treated as an argument.
117 |
118 |
arg...
119 |
120 | Specify arguments that are accessible using the #<argv> function.
121 |
122 |
123 |
Java Command Line Format
124 | The java invocation of ttm differs from the C version as follows.
125 |
126 |
Invoke using the command java -jar ttm.jar args....
127 |
Options may only be specified once.
128 |
The options are specified using the java -D command line mechanism.
129 | The options are encoded as follows.
130 |
131 |
-Dexec=string &mdash equivalent to the C -e flag.
132 |
-Dinteractive &mdash equivalent to the C -i flag.
133 |
-Dprogram=filepath &mdash equivalent to the C -p flag.
134 |
-Dinput=filepath &mdash equivalent to the C -f flag.
135 |
-Doutput=filepath &mdash equivalent to the C -o flag.
136 |
-Drsfile=filepath &mdash equivalent to the C -r flag.
137 |
-Dverbose &mdash equivalent to the C -V flag.
138 |
-DX=string &mdash equivalent to the C -X flag. The string
139 | is of the form :,:...
140 | 1
-Ddebug=string &mdash equivalent to the C -d flag.
141 |
142 |
143 |
144 |
Python Command Line Format
145 | The python invocation of ttm is essentially
146 | the same as the C command line.
147 |
148 | python ttm.py <command line arguments>
149 |
150 |
151 |
OVERALL OPERATION
152 | The ttm macro processor starts
153 | by scanning any commands specified by the
154 | -e or -p options.
155 | Any result is discarded.
156 | The idea is that these options establish the environment
157 | in which to scan the input file.
158 |
159 | Next, the interpreter scans the -f input file, if specified,
160 | and executes any macro invocations encountered. Any resulting output
161 | is sent to the file specified by the -o option. If not specified,
162 | the output is sent to standard output.
163 |
164 | Finally, if the -i flag is specified, then the interpreter goes
165 | into a read-eval loop. It reads "balanced" strings
166 | from the standard input,
167 | scans the input and repeats.
168 | If no -i is specified, the interpreter exits.
169 |
170 | The term balanced means that input is read until
171 | all instances of '<' have a matching '>'. Once balanced,
172 | input reading will stop at the currently defined EOL meta-character.
173 |
174 | Any arguments after the file name are provided to ttm using the
175 | #<argv;i> function.
176 |
177 | It is assumed that TTM is given a text file (via e.g. -f)
178 | containing some combination
179 | of ordinary text and TTM function calls (i.e. invocations).
180 | The text is scanned character by character. Any ordinary text is passed
181 | to the output unchanged (taking escapes into consideration).
182 | If a TTM function is encountered, it is collected and executed.
183 |
184 |
SYNTAX AND SEMANTICS
185 | The general form of a TTM function call looks like this.
186 |
187 | #<functionname;arg1;arg2;...;argn>
188 |
189 | where the functionname and the arguments are arbitrary character strings
190 | not characters of significance: '#', '<', '>', and ';'.
191 | The function is invoked with the specified arguments and the resulting
192 | text is inserted into the original text in place of the function call.
193 | If the function call was prefixed by a single '#' character, then scanning
194 | will resume just before the inserted text from the function call. If the
195 | function call was prefixed by two '#' characters, then scanning
196 | resumes just after the inserted text.
197 |
198 | During the collection of a function call, additional function calls
199 | may be encountered, for example, this.
200 |
203 | The nested function call will be invoked when encountered and the result
204 | inserted into the text of the outer function call and scanning of
205 | the outer function call resumes at the place indicated by the number
206 | of '#' characters preceding the nested call.
207 |
208 | If a function takes, for example, 2 arguments, any extras
209 | are ignored. For user defined functions, if too few arguments
210 | are provided, additional one are added with the value of the empty
211 | string ("").
212 |
213 | As with other applicative programming languages,
214 | a TTM function may be recursive and may be defined as the result
215 | of the invocation of a sequence of other function calls.
216 |
217 | Functions are either built-in or user defined.
218 | A large number of built-in
219 | functions exist and are defined in the TTM reference manual [1].
220 |
221 |
Function definition
222 | User defined functions are created using the following two built-in
223 | functions.
224 |
225 |
#<ds;name;text>
226 |
#<ss;name;text1;text2...;textn>
227 |
228 |
229 | The first function, ds for "define string",
230 | defines a named string in the TTM
231 | dictionary. The name is "name" and its value is "text".
232 | Invoking this named string will cause it's invocation to be replaced
233 | by the value (i.e. "text").
234 |
235 | The second function, ss for "segment string",
236 | scans the text of a previously defined string
237 | looking for occurrences of its arguments: text1, text2, ... textn.
238 | When an occurrence is found, it is replaced with a segment mark.
239 | All occurrences of each argument are replaced by the same segment mark.
240 |
241 | When a segmented string is invoked, each argument to the call
242 | is substituted for the corresponding segment mark.
243 | Consider this example.
244 |
249 | The string F is defined (line 1) and its body "abcxxdefyy"
250 | is segmented on the two strings "xx" and "yy" (line2).
251 | When invoked (line 3), it will return the value "abc11def22".
252 | In effect, we have a user defined function F with two arguments.
253 |
254 |
Escaping
255 | It is possible to escape one or more characters using either of two
256 | conventions.
257 |
258 |
<...> – escape multiple characters.
259 |
\ – escape a single character.
260 |
261 |
262 | If a string is enclosed in <...>, then it is scanned
263 | but not interpreted by TTM. In the scanning process, the outer
264 | < and > brackets are removed. If there are nested occurrences
265 | of <...>, then they are scanned but the '<' and '>' are not removed.
266 | The brackets must balance: the number of '<' characters
267 | must equal the number of '>' characters.
268 |
269 | The '\' escape convention causes the interpreter to pass as-is the character
270 | after the '\'. The leading '\' is left if it within a <...>
271 | escape sequence, otherwise it is removed. One use is to
272 | allow unbalanced occurrences of '<' or '>' characters
273 | [Note: in the reference implementation, '@' was changed to '\'].
274 |
275 |
Examples
276 |
277 |
Example 1: Function Definition
278 |
279 | The most basic example involves defining
280 | a function that is useful for defining addtional functions.
281 | This "meta" function is called def.
282 | It is written as:
283 |
288 | We can, for example, use def to define the string XX as
289 | 12345 and then segment XX on 34 by writing this.
290 |
291 | #<def;XX;34;12345>
292 |
293 |
294 | The call
295 |
296 | #<XX;0000>
297 |
298 | will then produce the string "1200005".
299 |
300 | The def function operates by invoking ds to define the function
301 | being defined — XX in our example — and then segmenting the body
302 | of XX by any specified arguments: "34" in this case. When XX is invoked,
303 | its argument is substituted for the segment mark.
304 |
305 |
Example 2: Factorial
306 | The factorial function can be defined (using the above #<def> function)
307 | as follows.
308 |
311 | Notice that the inner computation (#<mu...) is escaped
312 | so it will only be evaluated after the #<lt... function
313 | is executed and returns that nested computation as its result.
314 |
315 | An example call would look like this.
316 | #<n!;3>
317 | and would return the string 6.
318 |
319 |
MODIFICATIONS
320 | This ttm processor adheres closely to the specification in the
321 | ttm specification documents [1,2].
322 |
323 | However, the following general changes to TTM should be noted.
324 |
325 |
326 |
The escape character is changed from '@' to '\'.
327 |
328 |
The end of input meta character is changed from ''' (i.e. single quote)
329 | to '\n' (i.e. newline).
330 |
331 |
332 | Escape handling is slightly different and adheres more closely
333 | to the Unix rules. Specifically, the following escape sequences,
334 | when occurring outside of <...>, are translated as follows.
335 |
336 |
Escape Sequence
Translation
337 |
\r
carriage return
338 |
\n
line feed
339 |
\t
tab
340 |
\b
backspace
341 |
\f
form feed
342 |
343 | Additionally, if an escape occurs at the end of a line,
344 | then that end of line is ignored. This allows one to
345 | provide some formatting for function invocations without
346 | necessarily having to clutter up the result with new lines.
347 |
348 |
Only lower case built-in function names are supported.
349 |
350 |
351 | This version of ttm supports (more or less) utf-8. The meta characters
352 | are restricted to be a subset of the US-ASCII 7-bit subset of utf-8.
353 | Otherwise, strings may contain any legal utf-8 multi-byte character.
354 | This allows for inclusion of utf-8 codepoints, but only limited validation
355 | is performed to see if the string is truly utf-8.
356 |
357 | Internally, and in the C implementation,
358 | all characters are represented as 32-bit UTF characters.
359 | This wastes some space, but makes processing simpler.
360 | For Python and Java, characters are represented internally
361 | in UTF-16 because they provide native support for that format.
362 |
363 |
364 |
365 |
A Note on Segment Marks
366 | In this implementation, segment (and creation) marks
367 | are represented as a single 32-bit integer, where the value zero
368 | indicates a creation mark and any integer greater than zero
369 | indicates the n'th segment mark.
370 | The integer has bits set so that is is not a legal UTF character.
371 |
372 | One more point about segment marks. It is possible using #<gn>, for
373 | example, to output a string with segment marks in it. The original
374 | documentation is silent on how such segment marks are to be treated.
375 | In this implementation, they are included. If an attempt is made to print
376 | them, they are converted to the form '^n' where n is the segment mark.
377 |
378 |
New Functions
379 | A number of new functions have been implemented and are describe below
380 | using a notation similar to that in [1].
381 |
382 | ttm
383 | Specification: ttm,2,*,S
384 | Invocation: #<ttm;cmd;arg1;arg2;...>
385 | This function provides a general mechanism for embedding
386 | special commands to extract or alter interpreter information.
387 | The currently defined commands are as follows.
388 |
389 |
Command
Description
390 |
#<ttm;meta;metachars>
391 | Change the set of meta-characters.
392 | It takes one argument that specifies the set of
393 | meta characters. Setting the default behavior would use
394 | this invocation: #<ttm;meta; \#\<\;\>\\>.
395 | Note that this is separate from the CM function.
396 |
397 |
#<ttm;info;subcommands;...>
398 | Dump information about internal ttm structures.
399 | The currently defined subcommands for info are as follows.
400 |
401 |
SubCommand
Description
402 |
#<ttm;info;name;name1;name2...>
403 | Return info about each namei.
404 |
#<ttm;info;class;class1;class2...>
405 | Return info about each classi.
406 |
407 |
408 |
409 |
410 | include
411 | Specification:
include,1,1,S
412 | Invocation: #<include;filename>
413 | Read the contents of the specified file into the buffer and
414 | continue processing. For security reasons, the constraint
415 | is imposed that the file name must only be accessible
416 | through one of the include paths (i.e. using -I on the
417 | command line). This has the possibly undesirable
418 | consequence that if the user used #<include>, then the user
419 | must also specify a -I on the command line. This constraint
420 | also implies that the parameter filename must be a
421 | relative path. If the result from reading the file is unwanted,
422 | then one should use "-e #<include;filename>" on the command line.
423 |
424 |
#<argv;i>
428 | Return the i'th command line argument
429 | starting at 1 (like C).
430 | The parameter i should be a a non-negative
431 | integer. An argument of zero will return
432 | the invoking command's name. If the index
433 | is out of bounds, then a fatal error occurs
434 | => use the #<argc> function.
435 |
436 |
#<classes>
448 | Return the names of all defined character classes
449 | arranged in sorted order and separated by commas.
450 |
451 |
452 | pf
453 | Specification: pf,0,1,S
454 | Invocation: #<pf;stderr>
455 | If no arguments are given, then flush stdout and stderr.
456 | If the single argument is the string 'stderr',
457 | then flush stderr.
458 | If the single argument is the string 'stdout'
459 | then flush stdout.
460 |
461 |
Modifications to Function Semantics
462 | The semantics of the following functions others have been changed.
463 |
464 | ad
465 | Specification: ad,2,*,V
466 | Invocation: #<ad;num1;...numn>
467 | This function normally takes only two arguments.
468 | It has been extended to take an arbitrary number
469 | of arguments and return the sum of all of the arguments.
470 |
471 |
472 | mu
473 | Specification: mu,2,*,V
474 | Invocation: #<mu;num1;...numn>
475 | This function normally takes only two arguments.
476 | It has been extended to take an arbitrary number
477 | of arguments and return the product of all of the arguments.
478 |
479 |
480 | ps
481 | Specification: ps,1,2,S
482 | Invocation: #<ps;string;stderr>
483 | This function normally prints the string on
484 | stdout. If the second argument is the string
485 | "stderr", however, then it prints to stderr.
486 |
487 |
488 | psr
489 | Specification: psr,1,1,S
490 | Invocation: #<psr;string>
491 | This function prints its argument to stdout
492 | and then reads from stdin up to the meta-character
493 | (see the cm function).
494 |
495 |
496 | cm
497 | Specification: cm,1,1,S
498 | Invocation: #<cm;string>
499 | This function specifies the character
500 | that is used to terminate input when using,
501 | for example #<rs>.
502 | The default meta-character has been changed
503 | from "'" to "\n". This means that as a rule,
504 | reading will read only a single line of input.
505 | One can, however use the escape character
506 | at the end of the line to read multiple lines
507 | with the escaped '\n' being elided.
508 |
509 |
510 | cf
511 | Specification: cf,2,2,S
512 | Invocation: #<cf;new-name;old-name>
513 | The original definition said that the body of
514 | old-name, including segment marks and beginning
515 | at the old-name's residual pointer was copied
516 | to the body of new-name.
517 | However, trying to figure out how to handle
518 | a set of segment marks with gaps is problematic.
519 | So, the definition has been modified to
520 | copy the whole body of the old-name
521 | as the body of the new name, ignoring (but duplicating)
522 | the residual pointer.
523 |
524 |
525 | exit
526 | Specification: exit,0,1,S
527 | Invocation: #<exit;exitcode>
528 | This was changed to allow optional specification
529 | of a return code.
530 |
531 |
532 | names
533 | Specification: exit,0,1,V
534 | Invocation: #<names>
535 | This was changed so that
536 | if the second argument is present, then
537 | all names are returned, otherwise only non-builtin
538 | names are returned.
539 |
540 |
541 | tn
542 | Specification: tn,0,*,V
543 | Invocation: #<tn;name1;...namen>
544 | This was changed so that only the specified function names
545 | will be traced. If there are no names provided, then all function
546 | invocations will be traced.
547 |
548 |
549 | tf
550 | Specification: tf,0,*,V
551 | Invocation: #<tn;name1;...namen>
552 | This was changed so that only the specified function names
553 | will have tracing turned off. If there are no names provided, then no
554 | function invocations will be traced. Note that turning off all tracing
555 | will turn off tracing on all specific function.
556 |
557 |
558 | ps
559 | Specification: ps,1,2,S
560 | Invocation: #<ps;string;stdxx>
561 | This was changed to an optional allow a second argument that
562 | specifies sending the output to either "stdout"
563 | or "stderr". If missing, then stdout is assumed.
564 |
565 |
566 | rs
567 | Specification: rs,0,0,S
568 | Invocation: #<rs>
569 | Read a string of characters until either EOF
570 | or the defined "end-of-input" character is reached.
571 |
572 |
573 | rs
574 | Specification: rs,0,0,S
575 | Invocation: #<rs>
576 | In order to avoid spoofing, the string 'ttm>' is printed
577 | before reading.
578 |
579 |
580 | The time function from the interactive version differs from
581 | that of the batch version. The interactive time function
582 | corresponds to the batch xtime function and the batch time
583 | function returns time of day instead of execution time.
584 | The batch versions of time and xtime are implemented.
585 | In additon, ctime is implemented to give time of day
586 | in Unix ctime format.
587 |
588 | time
589 | Specification: time,0,0,V
590 | Invocation: #<time>
591 | Returns the time of day in 100'ths of second
592 | from ?.
593 |
594 | xtime
595 | Specification: xtime,0,0,V
596 | Invocation: #<time>
597 | Returns the execution time in 100'ths of second.
598 |
599 | ctime
600 | Specification: ctime,1,1,V
601 | Invocation: #<ctime;time>
602 | Convert the time (the result of a call to #<time>)
603 | to a printable string as defined by the Unix ctime function.
604 |
605 |
606 | A number of functions (#<gn>, $<cn>, etc.)
607 | are supposed to return some fixed number of characters.
608 | The original documentation is silent about what should
609 | happen if there are not enough characters available to return.
610 | In this implementation, whatever characters are available are returned,
611 | even if less than the number requested.
612 |
613 |
IMPLEMENTED FUNCTIONS
614 | The following functions from the original ttm
615 | are implemented.
616 |
617 |
618 |
619 |
abs,1,1,V
620 |
ad,2,2,V
621 |
ap,2,2,S
622 |
cc,1,1,SV
623 |
624 |
ccl,2,2,SV
625 |
cf,2,2,S
626 |
cm,1,1,S
627 |
cn,2,2,SV
628 |
629 |
cp,1,1,SV
630 |
cr,2,2,S
631 |
cs,1,1,SV
632 |
ctime,1,1,V
633 |
634 |
dcl,2,2,S
635 |
dncl,2,2,S
636 |
ds,2,2,S
637 |
dv,2,2,V
638 |
639 |
dvr,2,2,V
640 |
ecl,1,*,S
641 |
eos,3,3,V
642 |
eq,4,4,V
643 |
644 |
eq?,4,4,V
645 |
es,1,*,S
646 |
exit,0,0,S
647 |
flip,1,1,V
648 |
649 |
gn,2,2,V
650 |
gt,4,4,V
651 |
gt?,4,4,V
652 |
isc,4,4,SV
653 |
654 |
lt,4,4,V
655 |
lt?,4,4,V
656 |
mu,2,2,V
657 |
names,0,1,V
658 |
659 |
ndf,3,3,V
660 |
norm,1,1,V
661 |
ps,1,2,S
662 |
psr,1,1,SV
663 |
664 |
rrp,1,1,S
665 |
rs,0,0,V
666 |
sc,2,63,SV
667 |
scl,2,2,S
668 |
669 |
scn,3,3,SV
670 |
sn,2,2,S
671 |
ss,2,2,S
672 |
su,2,2,V
673 |
674 |
tcl,4,4,V
675 |
tf,0,0,S
676 |
time,0,0,V
677 |
tn,0,0,S
678 |
679 |
xtime,0,0,V
680 |
zlc,1,1,V
681 |
zlcp,1,1,V
682 |
683 |
684 |
UNIMPLEMENTED FUNCTIONS
685 | The following functions from the original ttm
686 | are not implemented.
687 |
688 |
rcd,2,2,S
fm,1,*,S
tabs,1,8,S
scc,2,2,S
689 |
icc,1,1,S
outb,0,3,S
store,2,2,S
delete,1,1,S
690 |
copy,1,1,S
show,0,1,S
libs,2,2,S
break,0,1,S
691 |
692 |
693 | The following functions from the batch ttm
694 | are not implemented.
695 |
696 |
697 |
insw,2,2,S
698 |
ttmsw,2,2,S
699 |
cd,0,0,V
700 |
cdsw,2,2,S
701 |
for,0,0,V
702 |
forsw,2,2,S
703 |
pk,0,0,V
704 |
pksw,2,2,S
705 |
ps,1,1,S
706 |
page,1,1,S
707 |
sp,1,1,S
708 |
fm,0,*,S
709 |
tabs,1,10,S
710 |
scc,3,3,S
711 |
fmsw,2,2,S
712 |
des,1,1,S
713 |
714 |
715 |
BUGS
716 |
717 |
718 |
The windows solution will build and run under Visual Studio C++ 2010,
719 | but the resulting ttm.exe fails when run standalone.
720 |
738 |
739 | The original ttm was designed and implemented
740 | by Steven H. Caine and E. Kent Gordon.
741 | (http://www.cfg.com/).
742 |
743 |
REFERENCES
744 |
745 |
Caine, S.H. and Gordon, E.K.,
746 | TTM: An Experimental Interpretive Language.
747 | California Institute of Technology, Willis H. Booth Computing Center, Programming Report No. 7, 1968.
748 |
Caine, S.H. and Gordon, E.K.,
749 | TTM: A Macro Language for Batch Processing.
750 | California Institute of Technology, Willis H. Booth Computing Center, Programming Report No. 8 May, 1969.
751 |
Farber, D. J., 635 Assembly System - GAP. Bell Telephone Laboratories Computation Center (1964).
752 |
Strachey, C., A General Purpose Macro Generator. Comput J 8, 3(1965), pp. 225-241..
753 |
754 |