Mercurial > hg > xemacs-beta
view src/lisp-disunion.h @ 939:025200a2163c
[xemacs-hg @ 2002-07-31 07:23:39 by michaels]
2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de>
Markus Kaltenbach <makalten@informatik.uni-tuebingen.de>
Mike Sperber <mike@xemacs.org>
configure flag to turn these changes on: --use-kkcc
First we added a dumpable flag to lrecord_implementation. It shows,
if the object is dumpable and should be processed by the dumper.
* lrecord.h (struct lrecord_implementation): added dumpable flag
(MAKE_LRECORD_IMPLEMENTATION): fitted the different makro definitions
to the new lrecord_implementation and their calls.
Then we changed mark_object, that it no longer needs a mark method for
those types that have pdump descritions.
* alloc.c:
(mark_object): If the object has a description, the new mark algorithm
is called, and the object is marked according to its description.
Otherwise it uses the mark method like before.
These procedures mark objects according to their descriptions. They
are modeled on the corresponding pdumper procedures.
(mark_with_description):
(get_indirect_count):
(structure_size):
(mark_struct_contents):
These procedures still call mark_object, this is needed while there are
Lisp_Objects without descriptions left.
We added pdump descriptions for many Lisp_Objects:
* extents.c: extent_auxiliary_description
* database.c: database_description
* gui.c: gui_item_description
* scrollbar.c: scrollbar_instance_description
* toolbar.c: toolbar_button_description
* event-stream.c: command_builder_description
* mule-charset.c: charset_description
* device-msw.c: devmode_description
* dialog-msw.c: mswindows_dialog_id_description
* eldap.c: ldap_description
* postgresql.c: pgconn_description
pgresult_description
* tooltalk.c: tooltalk_message_description
tooltalk_pattern_description
* ui-gtk.c: emacs_ffi_description
emacs_gtk_object_description
* events.c:
* events.h:
* event-stream.c:
* event-Xt.c:
* event-gtk.c:
* event-tty.c:
To write a pdump description for Lisp_Event, we converted every struct
in the union event to a Lisp_Object. So we created nine new
Lisp_Objects: Lisp_Key_Data, Lisp_Button_Data, Lisp_Motion_Data,
Lisp_Process_Data, Lisp_Timeout_Data, Lisp_Eval_Data,
Lisp_Misc_User_Data, Lisp_Magic_Data, Lisp_Magic_Eval_Data.
We also wrote makro selectors and mutators for the fields of the new
designed Lisp_Event and added everywhere these new abstractions.
We implemented XD_UNION support in (mark_with_description), so
we can describe exspecially console/device specific data with XD_UNION.
To describe with XD_UNION, we added a field to these objects, which
holds the variant type of the object. This field is initialized in
the appendant constructor. The variant is an integer, it has also to
be described in an description, if XD_UNION is used.
XD_UNION is used in following descriptions:
* console.c: console_description
(get_console_variant): returns the variant
(create_console): added variant initialization
* console.h (console_variant): the different console types
* console-impl.h (struct console): added enum console_variant contype
* device.c: device_description
(Fmake_device): added variant initialization
* device-impl.h (struct device): added enum console_variant devtype
* objects.c: image_instance_description
font_instance_description
(Fmake_color_instance): added variant initialization
(Fmake_font_instance): added variant initialization
* objects-impl.h (struct Lisp_Color_Instance): added color_instance_type
* objects-impl.h (struct Lisp_Font_Instance): added font_instance_type
* process.c: process_description
(make_process_internal): added variant initialization
* process.h (process_variant): the different process types
author | michaels |
---|---|
date | Wed, 31 Jul 2002 07:23:39 +0000 |
parents | 804517e16990 |
children | 184461bc8de4 |
line wrap: on
line source
/* Fundamental definitions for XEmacs Lisp interpreter -- non-union objects. Copyright (C) 1985, 1986, 1987, 1992, 1993 Free Software Foundation, Inc. Copyright (C) 2001, 2002 Ben Wing. This file is part of XEmacs. XEmacs is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. XEmacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with XEmacs; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* Synched up with: FSF 19.30. Split out from lisp.h. */ /* This file has diverged greatly from FSF Emacs. Syncing is no longer desirable or possible */ /* Format of a non-union-type Lisp Object 3 2 1 0 bit 10987654321098765432109876543210 -------------------------------- VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVTT Integers are treated specially, and look like this: 3 2 1 0 bit 10987654321098765432109876543210 -------------------------------- VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVT For integral Lisp types, i.e. integers and characters, the value bits are the Lisp object. Some people call such Lisp_Objects "immediate". The object is obtained by masking off the type bits. Bit 1 is used as a value bit by splitting the Lisp integer type into two subtypes, Lisp_Type_Int_Even and Lisp_Type_Int_Odd. By this trickery we get 31 bits for integers instead of 30. For non-integral types, the value bits of a Lisp_Object contain a pointer to a structure containing the object. The pointer is obtained by masking off the type and mark bits. All pointer-based types are coalesced under a single type called Lisp_Type_Record. The type bits for this type are required by the implementation to be 00, just like the least significant bits of word-aligned struct pointers on 32-bit hardware. This requires that all structs implementing Lisp_Objects have an alignment of at least 4 bytes. Because of this, Lisp_Object pointers don't have to be masked and are full-sized. There are no mark bits in the Lisp_Object itself (there used to be). Integers and characters don't need to be marked. All other types are lrecord-based, which means they get marked by setting the mark bit in the struct lrecord_header. Here is a brief description of the following macros: XTYPE The type bits of a Lisp_Object XPNTRVAL The value bits of a Lisp_Object storing a pointer XCHARVAL The value bits of a Lisp_Object storing a Ichar XREALINT The value bits of a Lisp_Object storing an integer, signed XUINT The value bits of a Lisp_Object storing an integer, unsigned INTP Non-zero if this Lisp_Object is an integer Qzero Lisp Integer 0 EQ Non-zero if two Lisp_Objects are identical, not merely equal. */ typedef EMACS_INT Lisp_Object; #define Lisp_Type_Int_Bit (Lisp_Type_Int_Even & Lisp_Type_Int_Odd) #define VALMASK (((1UL << VALBITS) - 1UL) << GCTYPEBITS) #define XTYPE(x) ((enum Lisp_Type) (((EMACS_UINT)(x)) & ~VALMASK)) #define XPNTRVAL(x) (x) /* This depends on Lisp_Type_Record == 0 */ #define XCHARVAL(x) ((x) >> GCBITS) #define XREALINT(x) ((x) >> INT_GCBITS) #define XUINT(x) ((EMACS_UINT)(x) >> INT_GCBITS) #define wrap_pointer_1(ptr) ((Lisp_Object) (ptr)) DECLARE_INLINE_HEADER ( Lisp_Object make_int_verify (EMACS_INT val) ) { Lisp_Object obj = (Lisp_Object) ((val << INT_GCBITS) | Lisp_Type_Int_Bit); type_checking_assert (XREALINT (obj) == val); return obj; } #define make_int(x) ((Lisp_Object) (((x) << INT_GCBITS) | Lisp_Type_Int_Bit)) #define volatile_make_int(x) make_int (x) #define make_char_1(x) ((Lisp_Object) (((x) << GCBITS) | Lisp_Type_Char)) #define INTP(x) ((EMACS_UINT)(x) & Lisp_Type_Int_Bit) #define INT_PLUS(x,y) ((x)+(y)-Lisp_Type_Int_Bit) #define INT_MINUS(x,y) ((x)-(y)+Lisp_Type_Int_Bit) #define INT_PLUS1(x) INT_PLUS (x, make_int (1)) #define INT_MINUS1(x) INT_MINUS (x, make_int (1)) #define Qzero make_int (0) #define Qnull_pointer ((Lisp_Object) 0) #define EQ(x,y) ((x) == (y)) /* WARNING!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! You can only VOID_TO_LISP something that had previously been LISP_TO_VOID'd. You cannot go the other way, i.e. create a bogus Lisp_Object. If you want to stuff a void * into a Lisp_Object, use make_opaque_ptr(). */ /* Convert between a (void *) and a Lisp_Object, as when the Lisp_Object is passed to a toolkit callback function */ #define VOID_TO_LISP(varg) ((Lisp_Object) (varg)) #define LISP_TO_VOID(larg) ((void *) (larg)) /* Convert a Lisp_Object into something that can't be used as an lvalue. Useful for type-checking. */ #define NON_LVALUE(larg) ((larg) + 0)