summaryrefslogtreecommitdiffstats
path: root/tl.vim
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 /tl.vim
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 'tl.vim')
0 files changed, 0 insertions, 0 deletions