summaryrefslogtreecommitdiffstats
path: root/buf.h
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2018-04-12 19:57:17 -0700
committerKaz Kylheku <kaz@kylheku.com>2018-04-12 19:57:17 -0700
commit69d9874359752a68a61055c1117a06aae7cb4f1d (patch)
tree8a1b2c8402ea0afee63505e453b6c72ef60572bf /buf.h
parent0bdcbc08658036dbf46142c1fb41e320e6019148 (diff)
downloadtxr-69d9874359752a68a61055c1117a06aae7cb4f1d.tar.gz
txr-69d9874359752a68a61055c1117a06aae7cb4f1d.tar.bz2
txr-69d9874359752a68a61055c1117a06aae7cb4f1d.zip
compile-file: need endian mark in .tlo files.
VM machine code is endian-specific: it consists of 32 bit instruction words which are 32 bit in the local byte order. Thus code assembled on a little-endian machine won't run on a big endian-machine, or vice versa: unless we identify the situation and byte-swap the code when we load it. * buf.c (buf_swap32): New function. * buf.h (buf_swap32): Declared. * parser.c (read_file_common): Decode the third element from the version: a Boolean indicating big endian, if true. If the object file's endian is opposite from our endian, then byte swap the code. * itypes.c (itypes_init): Oops, calculation of itypes_little_endian was broken due to classic C =/== typo. Luckily, nothing has used this flag so far; it's been waiting for this first use. I caught this due to testing on a PPC64 box. * share/txr/stdlib/compiler.tl (%big-endian%, %tlo-ver%): New variables. (usr:compile-file): The file version comes from %tlo-ver% now, which includes the big-endian flag.
Diffstat (limited to 'buf.h')
-rw-r--r--buf.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/buf.h b/buf.h
index 107d7608..cf394ff0 100644
--- a/buf.h
+++ b/buf.h
@@ -106,4 +106,6 @@ val buf_pprint(val buf, val stream);
val make_buf_stream(val buf_opt);
val get_buf_from_stream(val stream);
+void buf_swap32(val buf);
+
void buf_init(void);