[MLton-devel] Fwd: C back end for MLton (fwd)

[Stephen Weeks]

> I'm still a bit confused.  I see the following choices:
> 	use / directly, no function call
> 	use / in the definition of the function, not inlined, and then use
> 		the function call.
> 	use inlined assembler
> The first fails because of the negative arg case.  The second still does a
> function call.  The third is best, except for the fact that won't do constant
> folding (which only the first would do).

I was planning on option 2.  My guess is that the history is as
follows.

1. We used to have Int_quot as a macro using / in ccodegen.h.
2. We discovered the bugs similar to what you are talking about due to
	the flexibility allowed by the C standard
3. We switched to using inline asm, defining Int_quot as a static inline
4. We found more bugs, either due to gcc bugs or our incomplete
	understanding of inline asm
5. We moved Int_quot into its own file to avoid those headaches.

Somewhere around step 4, the native codegen came along, and we didn't
care as much about performance of the C codegen, making 5 a more
reasonable decision.

If somebody cares about improving the C codegen, we can suggest to
them that they try the static inline + inline assembler.  But I think
for our purposes it makes more sense to stay with something that we
are more confident of it's correctness.  So I vote for your option 2,
although if you believe in 3, want to try it, run through all the
regressions, and they pass, then I'll put it in.


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel