[Sbcl-devel] Some simplification of assembler.

[Heka Treep]

Hello. I made a slight simplification, here it is.

First, parameter *assembly-unit-length* (the number of bits per
element in the assemblers code vector) is defined in
`compiler/$ARCH/params.lisp' for x86, ppc, and sparc platforms but
don't used anywhere. I delete it, everyone shoud use
`sb!vm:n-byte-bits' or `sb-vm:n-widetag-bits' or
`sb!assem::assembly-unit-bits' for this.

On all platforms constant `n-byte-bits' (which defined in
`compiler/$ARCH/params.lisp'.) is equal to 8, in
`compiler/generic/early-vm.lisp' I redefine `n-widetag-bits' as equal
to `n-byte-bits' (not just 8).

Next, that is comment from `compiler/early-assem.lisp':

;;; FIXME: It might make sense to use SB!VM:BYTE-FOO values here
;;; instead of the various ASSEMBLY-UNIT-FOO things, and then define a
;;; BYTE type. One problem: BYTE is exported from the CL package, so
;;; ANSI says that we're not supposed to be attaching any new meanings
;;; to it. Perhaps rename SB!VM:BYTE-FOO to SB!VM:VMBYTE-FOO or
;;; SB!VM:VM-BYTE-FOO, and then define the SB!VM:VMBYTE or
;;; SB!VM:VM-BYTE types?
;;;
;;; If this was done, some of this file could go away, and the rest
;;; could probably be merged back into assem.lisp. (This file was
;;; created simply in order to move the ASSEMBLY-UNIT-related
;;; definitions before compiler/generic/core.lisp in the build
;;; sequence.)

I define `vm-byte', `vm-signed-byte' and `vm-possibly-signed-byte'
types in `compiler/generic/early-vm.lisp'.

ASSEMBLY-UNIT-* staff required only in `compiler/assem.lisp',
`compiler/dump.lisp' and `compiler/generic/target-core' (not in
`core.lisp' as `base-target-features.lisp-expr' says),
`compiler/dump.lisp' and `compiler/generic/target-core' is later than
`compiler/assem.lisp' in build order, so I move `early-assem.lisp'
code to the head of the `assem.lisp' file.

So, at this time:

* sb!assem::assembly-unit-bits = sb!vm:n-widetag-bits = sb!vm:n-byte-bits
* sb!assem::assembly-unit-mask = sb!vm:widetag-mask
* sb!assem:assembly-unit is sb!vm:vm-byte
* sb!assem::possibly-signed-assembly-unit is sb!vm:vm-possibly-signed-byte
* and sb!assem::max-alignment is sb!vm:n-lowtag-bits

It is possible to delete all ASSEMBLY-UNIT-* things and use things
from the SB!VM package, but I thing that ASSEMBLY-UNIT names looks
goods in SB!ASSEM package.

[Nikodemus Siivola]

On 15 September 2010 21:03, Heka Treep <zena....@gmail.com> wrote:

Thank you for the patch. Some comments:

+(def!constant assembly-unit-bits sb!vm:n-widetag-bits)
+(def!constant assembly-unit-mask sb!vm:widetag-mask)

N-WIDETAG-BITS is wrong. It is 8, but it could be something else.
Widetag size is conceptually separate from byte-width.

This should either remain a literal 8, unless assembly-unit-bits is
removed entirely, in which case replacing it at use-sites with
n-byte-bits sounds like TRT.

Ditto for WIDETAG-MASK, obviously.

;;; the number of bits used in the header word of a data block to store
;;; the type
-(def!constant n-widetag-bits 8)
+(def!constant n-widetag-bits n-byte-bits)

Same thing here: it should remain a literal.

+(def!type vm-byte ()
+ `(unsigned-byte ,n-widetag-bits))
+
+(def!type vm-signed-byte ()
+ `(signed-byte ,n-widetag-bits))
+

VM-BYTE and and VM-SIGNED-BYTE would be better named OCTET and
SIGNED-OCTET, I think. While the old FIXME talks about VM-BYTE and
similar, a prefix like that isn't really ideal in my mind.

However, given that they aren't used much anywhere at all, I think
right now my preference would be to not have them at all and rather
define ASSEMBLY-UNIT and POSSIBLY-SIGNED-ASSEMBLY-UNIT directly from
ASSEMBLY-UNIT-BITS as is done currently.

+(def!type vm-possibly-signed-byte ()
+ '(or vm-byte
+ vm-signed-byte))

This seems like a useless type since POSSIBLY-SIGNED-ASSEMBLY-UNIT is
its only consumer: the union type belongs there, I think.

Cheers,

-- Nikodemus

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Heka Treep]

Hi, Nikodemus, thanks for review. I was on wikipedia where reading
what the byte is (and about supercomputers with 32 bit bytes), so
OCTET is a good name, I placed type definitions into `vm-type.lisp'
(instead of `early-vm.lisp' in the first version of the patch). Also,
I took back the eight literals.

But there are few places (the consumers) in the source where the types
(unsigned-byte 8), (signed-byte 8) and even (or (unsigned-byte 8)
(signed-byte 8)) are used in the declarations - so maybe they should
be replaced by an OCTET and friends?

In any case, the `early-assem.lisp' file and the
*assembly-unit-length* parameter should go away.

2010/9/29, Nikodemus Siivola <niko...@random-state.net>:

[Heka Treep]

Hello again, I was split these changes on the three trivial patch. The
first three eliminates the three FIXME. The last one can be skipped
because it introduces the OCTET types, but I don't know where they can
be used, (unsigned-byte 8) or (or (unsigned-byte 8) (signed-byte 8))
types looks resonable everywhere.

2010/10/2, Heka Treep <zena....@gmail.com>: