---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A439F9601CC; Wed, 28 Jan 2004 11:57:45 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CC1427@cherry.ease.lsoft.com>; Wed, 28 Jan 2004 14:57:27 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 5993 for PICLIST@MITVMA.MIT.EDU; Wed, 28 Jan 2004 14:57:19 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 2289; Wed, 28 Jan 2004 14:57:11 -0500 Received: from smtp-out2.xs4all.nl [194.109.24.12] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 14:57:10 EST X-Comment: mitvma.mit.edu: Mail was sent by smtp-out2.xs4all.nl Received: from PAARD (a213-84-20-53.adsl.xs4all.nl [213.84.20.53]) by smtp-out2.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0SJvCTH072995 for ; Wed, 28 Jan 2004 20:57:12 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <002201c3e5d8$ec05de10$0b00a8c0@PAARD> Date: Wed, 28 Jan 2004 20:57:12 +0100 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Wouter van Ooijen Organization: Van Ooijen Technische Informatica Subject: Re: [PIC:] duplicate device IDs in the 18F series To: PICLIST@MITVMA.MIT.EDU In-Reply-To: <401796A8.15468.AB848FB@localhost> Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856154 > > OK, but I said 'a solution without the use of a call vector'. > Yes, but I never promised such a thing. I a way you did. > One GOTO (or long-GOTO) per page, per subroutine that's called > from that page, doesn't seem like a lot of overhead to me. Not necesarrily per page. But for a 1k device: yes, it is still an overhead, which could have been avoid if that stupid 'sticky0' bit would have been placed elsewhere (LSB, MSB, but not in the middle!!). > If you just can't stand that "waste", though, it shouldn't be > hard to rearrange subroutines to minimize the number of call > vectors. I'd expect that JAL usually finds itself running on > a GHz-plus Athlon/Pentium 4... With that sort of power behind it, > even the clumsiest brute-force algorithm should be able to find > an optimized solution in milliseconds. Feel free to add it to the Jal compiler if you think it is that easy, the compiler is GPL :) Forgive my sarcasm, but it always pops up when someone states that something should be easy for someone else to do. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics .