[M3devel] Target.i3/Target.m3 reduction?

[Jay K]

There is fairly little target-dependent-ness in our system, aside from the gcc code.

I would like to reduce it.

There are a few forms:

There is dependency on word size.
  This I don't see removing any time soon, given
  that the front end does layout of records and
  computation of field offsets.
 

There is dependency on jumpbuf size.
  We mostly know how to remove this, but have failed so far.
  The generated code should use alloca for the locals.
  (and even then, longer term, don't use setjmp/longjmp).
  
  
We have these big arrays of targets, esp. in m3middle/src/Target.i3:
    PA32_HPUX,
    PA64_HPUX,
    PPC32_OPENBSD,
    PPC64_DARWIN,
    PPC_DARWIN,
    PPC_LINUX,
    ...

    
Many of the dependencies are really per architecture or per kernel,
not per architecture x kernel combination.
So this almost-cross product seems dumb.
Suggestions?


There is dependency on endianness.
This is what I'm really focusing on.
I think this only matters for interop with C bitfields.
We have no C bitfields in our system now.
And the frontend and backend I think have to agree...oh, nevermind, I don't see that in parse.c

 > Aligned_procedures
 
Just be safe and assume this is always false?
Or it is a nice optimization on the common x86/AMD64 platforms?


 > First_readable_addr
 
 Just hardcode this as 4K?
 Instead of the slight optimization of setting it to 8K for SPARC?
 
 > Allow_packed_byte_aligned
 
The safe value here is false.
We set it to true only for x86/AMD64.
I think true is probably safe for all architectures but older Alphas.
?


 > Setjmp
 
This has the same value on platforms except VMS.
We can maybe provide a portably-named wrapper?
Maybe not, since this function is kind of special.


I have to go..

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20111103/64b95ad8/attachment-0001.html>