1Ok, here are my comments and suggestions about the LLVM instruction set.
2We should discuss some now, but can discuss many of them later, when we
3revisit synchronization, type inference, and other issues.
4(We have discussed some of the comments already.)
5
6
7o  We should consider eliminating the type annotation in cases where it is
8   essentially obvious from the instruction type, e.g., in br, it is obvious
9   that the first arg. should be a bool and the other args should be labels:
10
11	br bool <cond>, label <iftrue>, label <iffalse>
12
13   I think your point was that making all types explicit improves clarity
14   and readability.  I agree to some extent, but it also comes at the cost
15   of verbosity.  And when the types are obvious from people's experience
16   (e.g., in the br instruction), it doesn't seem to help as much.
17
18
19o  On reflection, I really like your idea of having the two different switch
20   types (even though they encode implementation techniques rather than
21   semantics).  It should simplify building the CFG and my guess is it could
22   enable some significant optimizations, though we should think about which.
23
24
25o  In the lookup-indirect form of the switch, is there a reason not to make
26   the val-type uint?  Most HLL switch statements (including Java and C++)
27   require that anyway.  And it would also make the val-type uniform 
28   in the two forms of the switch.
29
30   I did see the switch-on-bool examples and, while cute, we can just use
31   the branch instructions in that particular case.
32
33
34o  I agree with your comment that we don't need 'neg'.
35
36
37o  There's a trade-off with the cast instruction:
38   +  it avoids having to define all the upcasts and downcasts that are
39      valid for the operands of each instruction  (you probably have thought
40      of other benefits also)
41   -  it could make the bytecode significantly larger because there could
42      be a lot of cast operations
43
44
45o  Making the second arg. to 'shl' a ubyte seems good enough to me.
46   255 positions seems adequate for several generations of machines
47   and is more compact than uint.
48
49
50o  I still have some major concerns about including malloc and free in the
51   language (either as builtin functions or instructions).  LLVM must be
52   able to represent code from many different languages.  Languages such as
53   C, C++ Java and Fortran 90 would not be able to use our malloc anyway
54   because each of them will want to provide a library implementation of it.
55
56   This gets even worse when code from different languages is linked
57   into a single executable (which is fairly common in large apps).
58   Having a single malloc would just not suffice, and instead would simply
59   complicate the picture further because it adds an extra variant in
60   addition to the one each language provides.
61
62   Instead, providing a default library version of malloc and free
63   (and perhaps a malloc_gc with garbage collection instead of free)
64   would make a good implementation available to anyone who wants it.
65
66   I don't recall all your arguments in favor so let's discuss this again,
67   and soon.
68
69
70o  'alloca' on the other hand sounds like a good idea, and the
71   implementation seems fairly language-independent so it doesn't have the
72   problems with malloc listed above.
73
74
75o  About indirect call:
76   Your option #2 sounded good to me.  I'm not sure I understand your
77   concern about an explicit 'icall' instruction?
78
79
80o  A pair of important synchronization instr'ns to think about:
81     load-linked
82     store-conditional
83
84
85o  Other classes of instructions that are valuable for pipeline performance:
86     conditional-move		 
87     predicated instructions
88
89
90o  I believe tail calls are relatively easy to identify; do you know why
91   .NET has a tailcall instruction?
92
93
94o  I agree that we need a static data space.  Otherwise, emulating global
95   data gets unnecessarily complex.
96
97
98o  About explicit parallelism:
99
100   We once talked about adding a symbolic thread-id field to each
101   instruction.  (It could be optional so single-threaded codes are
102   not penalized.)  This could map well to multi-threaded architectures
103   while providing easy ILP for single-threaded onces.  But it is probably
104   too radical an idea to include in a base version of LLVM.  Instead, it
105   could a great topic for a separate study.
106
107   What is the semantics of the IA64 stop bit?
108
109
110
111
112o  And finally, another thought about the syntax for arrays :-)
113
114   Although this syntax:
115	  array <dimension-list> of <type>
116   is verbose, it will be used only in the human-readable assembly code so
117   size should not matter.  I think we should consider it because I find it
118   to be the clearest syntax.  It could even make arrays of function
119   pointers somewhat readable.
120
121