Also, schemified "thread", "io", "regexp", "schemify", and "expander"
layers are checked in. Overall, building Racket CS no longer requires
first building Racket BC.
The imported sources are from the `racket/ChezScheme` repository,
which branched from `cisco/ChezScheme`. The commit history is
preserved, but all of the commit IDs have shifted, because bootfiles
have been pruned from the history.
The "cs-bootstrap" package is now in the `racket/ChezScheme` repo,
because it needs to track the Chez Scheme implementation instead of
the Racket implementation.
Move "racket/src/cs/bootstrap" from the Racket source repository to
this one, because the bootstrapping implementation needs to track the
Chez Scheme source much more closely than the Racket implementation.
Currently, any Racket v7.1 or later works.
Also update "README.md" and "BUILDING" to get all the information
consistent and in sync with revised build options.
original commit: a9e6e99ea414b4625fe9705e4f3cfd62bbf38ae2
For example, if the number of floating-point registers in "x86_64.ss"
changes, now only one ".def" file has to change instead of 14 ".def"
files.
original commit: c79524cc3eb516d9bee1708c06b80e3688fdd2ff
Makefile and configure improvements turn on more checking with MinGW,
so fix the resulting warnings-as-errors.
original commit: df2ff94b2b878924b5ca925c48253d147f668e79
This commit does four things:
* Adds "pb.ss" and "pb.c", which implement a portable bytecode
backend and interpreter that is intended for bootstrapping. A
single set of pb bootfiles can support bootstrapping on all
platforms --- as long as the C compiler supports a 64-bit integer
type. The pb machine supports foreign calls for only a small set of
recognized prototypes, and it does not support foriegn callables.
Use `./configure --pb` to build the pb variant.
* Changes the kernel's casts between `ptr` and `void*` types. In a pb
build, the `ptr` type can be a 64-bit integer type while `void*` is
a 32-bit pointer type, so casts must go through an intermediate
integer type.
* Adjusts the compiler to accomodate run-time-determined endianness.
Making the compiler agnostic to word size is not practical, but
only a few pieces depend on the target machine's endianness, and
those can generally be deferred to a run-time choice of byte-based
operations. The one exception is that ftype bit fields are not
allowed unless accompanied by an explicit endianness declaration.
* Start reducing duplication among platform-specific makefiles. For
example, `Mf-ta6osx` chains to `Mf-a6osx` to avoid repeating most
of it. A lot more can be done here.
original commit: 97533fa9d8b8400b0dc1a890768c7d30c91257e0
All back ends had essentially the same `define-instruction`, just with
slightly more functionality, checking, or abstraction each case. The
newly shared version better sorts out some inherent run-time checks
versus safe-mode assertions related to fp and non-fp arguments.
original commit: c70836fa04eb33442fd3ca273ce9ca08ce877fec
Commit 023681947c fixed a problem cooperating with xform, but the
repair assumes xform. The "embed-in-c.rkt" test, for example, uses 3m
without xform (and instead uses macros like `MZ_GC_DECL_REG`.
It's not clear that adding to "HISTORY.txt" is all that useful. But as
long as we do, at least include milestones that were signficant enough
to mention in release announcements.
CS didn't always return a complete path when simplifying in
use-filesystem mode. On Windows, CS and BC were inconsistent with each
other and the Unix behavior.
A `\\?\RED\` path is Racket- and Windows-specific, and it's an extreme
corner case: a drive-relative absolute path that include elements that
must eb specially esacped. BC's `build-path` incorrectly allowed
`\\?\RED\` to extend an absolute path. CS's `build-path` incorrctly
allowed various absolute-path extensions, including `\\?\RED\` paths.
The documentation was slightly off.
Since file links and directory links on Windows are disjoint, and the
difference is relevant for operations such as deleting a file,
`link-exists?` is not enough information. Add `file-or-directory-type`
to provide more information and also avoid separate calls to
`file-exists?`, `directory-exists?`, etc.
The `delete-directory/files` function now uses `file-or-directory-type`
so that it will work right with Windows directory links.
Relevant to #3288
