[M3devel] subtle IR differences for platforms that are really the same
Jay K
jayk123 at hotmail.com
Sat Mar 11 13:38:51 CET 2017
Trying to get back into things..not sure I sent this from a while ago..
This is both a question and an explanation
of hopefully an uncoming chnage, if I figure it out.
Most platforms are almost the same.
For example I386_FREEBSD and I386_NETBSD.
You want their IR to generally be the same, along
as they aren't printing their actual target name.
And they mostly are.
Here is a difference for example:
jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt
--- I386_NETBSD/NullRd.mc.txt 2016-06-30 19:13:11.000000000 -0700
+++ I386_FREEBSD/NullRd.mc.txt 2016-06-30 19:13:23.000000000 -0700
@@ -44,7 +44,6 @@
declare_procedure NullRd__Length 1 Int.32 0 0 F * p.7
declare_param rd 4 4 Addr 34129018 F F 50 v.10
declare_local _result 4 4 Int.32 425470580 F F 50 v.11
- reveal_opaque 34129018 -885236436
declare_opaque 483796623 -1651526519
declare_proctype -2116580915 2 -915982019 2 0
declare_formal n -1746782238
@@ -85,6 +84,7 @@
declare_field closed 416 8 509158269
declare_field seekable 424 8 509158269
declare_field intermittent 432 8 509158269
+ reveal_opaque 34129018 -885236436
# Init
-----LINE 22 -----
begin_procedure p.5
One line of the IR is moved.
The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations).
What causes this?
Do we output sometimes in hash order?
And target affects that?
Or when buffers fill up, and target length can affect that?
I'd like to remove these differences.
If it is a buffer length matter, I might just expand the buffers,
as systems have far far more memory than when this was all written.
If it is hash ordering matter -- one should avoid outputting data
in hash order.
so:
1. if anyone knows the difference, please tell me, before I debug it?
2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all
be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size,
and maybe NT vs. Posix but probably not.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20170311/3efb6c87/attachment-0001.html>
More information about the M3devel
mailing list