Custom Query (1030 matches)

r11754 is workaround for a bug in how the lisp assembler encodes memory operands that are just a displacement.

To elaborate on that commit message, there are two ways on 32-bit x86 to encode a memory operand that's just a displacement.

For example, take the instruction:

0x806e6db:	mov    %fs:0x84,%ecx

The lisp assembler encodes this as:

0x806e6db:	0x64	0x8b	0x0c	0x25	0x84	0x00	0x00	0x00

Note that the modrm byte of 0x0c (00 001 100) means that a sib byte follows.

This could also be encoded as this shorter sequence (and the Unix assembler does so):

0x806e6db:	0x64	0x8b	0x0d	0x84	0x00	0x00	0x00

The modrm byte of 0x0d (00 001 101) here means that the displacement follows.

The reason that the lisp assembler selects the longer encoding is because it targeted x86-64 first. On x86-64, the modrm byte in the shorter sequence is redefined to mean that the displacement is RIP-relative. Therefore, the longer sib byte encoding is used to specify just a displacement.

The lisp assembler needs to be persuaded to emit the shorter encoding for 32-bit x86. When it does, we can recompile and bump fasl versions, etc., and remove the workaround in pc_luser_xp().

Trying to get an ns-window to accept mouse events by defining an accepts-first-responder method that returns T works in 64-bit CCL but not 32-bit. In 32-bit, clicking on the window produces the following error (in the altconsole):

Error: value T is not of the expected type (UNSIGNED-BYTE 32).

While executing: (:INTERNAL[Nsview acceptsFirstResponder]|), in process Initial(0).

Type :POP to abort, :R for a list of available restarts. Type :? for other options.

1 >

Code to reproduce follows. Run the code, then click on the resulting window.

(defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s))

(defun make-ns-window (x y &optional (title "Untitled"))

(let ((nsw (make-instance 'ns:ns-window

:with-content-rect (ns:make-ns-rect 0 0 x y) :style-mask 15 :backing #$NSBackingStoreBuffered :defer t)))

(#/setTitle: nsw (nsstr title)) (#/setReleasedWhenClosed: nsw nil) (#/center nsw) (#/orderFront: nsw nil) nsw))

(defclass nsview (ns:ns-view)

(container) (:metaclass ns:+ns-object))

(ccl::define-objc-method ((:boolean accepts-first-responder) nsview) t)

(setf w (make-ns-window 300 300)) (#/setContentView w (make-instance 'nsview))

Summary: 2D Bitmap arrays print non-readably, #2A(#*101010 #*010101) doesn't read as 2D array, barfs, ...AND... can't create a 2D bitmap using reader.

If you create a 2D bitmap using (make-array '(4 4) :element-type '(mod 2)) The result will print as #2A(#*0000 #*0000 #*0000 #*0000) When you read it back in, the reader barfs:

> Error: Reader error on #<CCL::RECORDING-CHARACTER-INPUT-STREAM #xC75FFE6>, near position 32:
>        Initial contents for #A is inconsistent with dimensions: #2A(#<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4>)

The related bug is that #1A(#*0000 #*0000 #*0000 #*0000) works "just fine" except it creates a 1D array.

Apparently there is no way to create a 2D bitmap from the reader.