On 27 May 2016 at 01:54, John Willis wrote:
>> The 8088/8086 had a 20-bit address bus, differing mainly in the width
>> of the *data* bus, and the later 80286 had a 16-bit address bus.
>>
>
> The 80286 had a 24-bit address bus (16MB)
Sorry! Typo. It's nearly 2AM here in Czechia. I think I need t
> The 8088/8086 had a 20-bit address bus, differing mainly in the width
> of the *data* bus, and the later 80286 had a 16-bit address bus.
>
The 80286 had a 24-bit address bus (16MB)
--
*John P. Willis*
Coherent Logic Development LLC
M: 575.520.9542
O: 575.524.1034
chocolatejolli...@gmail.com
On Fri, 27 May 2016, Liam Proven wrote:
So I was broadly right that the 8088/8086 sit somewhere on the
dividing line? That at least is good to know!
Of course.
That is exactly the point.
How you draw the line, determines which side it will fall, and it is right
in the middle, so many otherwise
On 24 May 2016 at 23:10, Fred Cisin wrote:
> Whether 8088 was an "8 bit" or "16 bit" processor depends heavily on how you
> define those.
> Or, you could phrase it, that the 8 bit processors at the time handled 64KiB
> of RAM.
OK, thank you all for the responses.
Rarely have I felt so lectured
Sean Conner writes:
> From a hardware perspective, the 68000 had a 16-bit bus and 24
> physical address lines
Actually 23 address lines to select a 16-bit word in memory, plus UDS
and LDS to select upper byte/lower byte/word.
On 5/24/2016 3:32 PM, Swift Griggs wrote:
On Tue, 24 May 2016, Fred Cisin wrote:
(OB_Picky: Due to the overlap of segment and offset, on machines that had 21
address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
instead of 1048576 (10h).
This was always the biggest pu
> On May 24, 2016, at 3:10 PM, Swift Griggs wrote:
>
> On Tue, 24 May 2016, Guy Sotomayor Jr wrote:
>> The initial implementation of the A20 gate was implemented by the
>> keyboard controller(!) because it was discovered late in the PC AT
>> development cycle and we couldn?t add more logic to
On Tue, 24 May 2016, Guy Sotomayor Jr wrote:
> The initial implementation of the A20 gate was implemented by the
> keyboard controller(!) because it was discovered late in the PC AT
> development cycle and we couldn?t add more logic to the board (but we
> could add some wires).
That's very bizz
> On May 24, 2016, at 2:32 PM, Swift Griggs wrote:
>
> On Tue, 24 May 2016, Fred Cisin wrote:
>> (OB_Picky: Due to the overlap of segment and offset, on machines that had 21
>> address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
>> instead of 1048576 (10h).
>
> This
> On May 24, 2016, at 1:29 PM, Liam Proven wrote:
>
> On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
>> Because the 808x was a 16-bit processor with 1MB physical addressing. I
>> would argue that for the time 808x was brilliant in that most other 16-bit
>> micros only allowed for 64KB physic
On Tue, 24 May 2016, Swift Griggs wrote:
This was always the biggest pustule on the facade of x86 to me. Gate A20
and other chicanery was nasty business. It always struck me as a hardware
hack to work around earlier bad design.
to work around earlier LIMITED design.
IFF 64K is reasonable for yo
It was thus said that the Great Fred Cisin once stated:
> On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
> >Because the 808x was a 16-bit processor with 1MB physical addressing. I
> >would argue that for the time 808x was brilliant in that most other 16-bit
> >micros only allowed for 64KB physi
On Tue, 24 May 2016, Fred Cisin wrote:
> (OB_Picky: Due to the overlap of segment and offset, on machines that had 21
> address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
> instead of 1048576 (10h).
This was always the biggest pustule on the facade of x86 to me. Gate A
It was thus said that the Great Liam Proven once stated:
> On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
> > Because the 808x was a 16-bit processor with 1MB physical addressing. I
> > would argue that for the time 808x was brilliant in that most other 16-bit
> > micros only allowed for 64KB p
On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
Because the 808x was a 16-bit processor with 1MB physical addressing. I
would argue that for the time 808x was brilliant in that most other 16-bit
micros only allowed for 64KB physical.
Whether 8088 was an "8 bit" or "16 bit" processor depends
al Message -
From: "Liam Proven"
To: "General Discussion: On-Topic and Off-Topic Posts"
Sent: Tuesday, May 24, 2016 1:29:48 PM
Subject: Re: strangest systems I've sent email from
On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
> Because the 808x was a 16-bit pro
On 22 May 2016 at 04:52, Guy Sotomayor Jr wrote:
> Because the 808x was a 16-bit processor with 1MB physical addressing. I
> would argue that for the time 808x was brilliant in that most other 16-bit
> micros only allowed for 64KB physical.
Er, hang on. I'm not sure if my knowledge isn't good e
On May 20, 2016, at 8:58 PM, Sean Conner wrote:
>
> Now, it may sound cavalier of me, but of the three compilers I use at
> work (gcc, clang, Solaris Sun Works thingy) I know how to get them to layout
> the structs exactly as I need them
You can do this in Common Lisp too, though. It sounds more
On Sun, 22 May 2016, Mouse wrote:
> > How can you have the type of `size_t' wider than the widest unsigned
> > integer type in the respective revision of the language standard?
>
> unsigned long long int isn't necessarily the largest integral type.
> Nor do I see anything requiring size_t to be n
>>> Why bother? Won't:
>>> size_t foo = ~0UL;
>>> do (~0ULL for C99)?
>> Only if size_t is no larger than unsigned long int (unsigned long
>> long int for the ULL version). I don't think that's guaranteed.
> How can you have the type of `size_t' wider than the widest unsigned
> integer typ
On May 22, 2016, at 6:09 AM, Mouse wrote:
>
> I've often thought about building a C implementation that goes out of
> its way to break assumptions like "integers are two's complement with
> no padding bits" or "floats are IEEE" or "nil pointers are all-bits-0"
> or "all pointers are the same size
On Sun, 22 May 2016, Mouse wrote:
> size_t foo = (size_t)-1;
> >>>size_t foo = -(size_t)1;
> >> size_t foo = (size_t)(-1);
> > Why bother? Won't:
> > size_t foo = ~0UL;
> > do (~0ULL for C99)?
>
> Only if size_t is no larger than unsigned long int (unsigned long long
size_t foo = (size_t)-1;
>>>size_t foo = -(size_t)1;
>> size_t foo = (size_t)(-1);
> Why bother? Won't:
> size_t foo = ~0UL;
> do (~0ULL for C99)?
Only if size_t is no larger than unsigned long int (unsigned long long
int for the ULL version). I don't think that's g
On Sun, May 22, 2016, Mouse wrote:
> >> Also, PostScript has a lot of language syntax, whereas FORTH has
> >> immediate words that act like language syntax. (The difference is
> >> that FORTH makes it possible to change those words, thereby changing
> >> the apparent syntax.)
> > What do you mean
On Sun, 22 May 2016, Guy Dawson wrote:
> >> I'm not even sure
> >
> >> size_t foo = (size_t)-1;
> >
> >> is legal,
> >
> > In C++, I don't know. In C, I'm fairly sure it's legal.
> >
> >> or even does what I expect it to do (namely---set foo to the largest
> >> size_t value possible (pre C9
On Sun, 22 May 2016, Mouse wrote:
> >>> First off, the C standard mandates that the order of fields in a
> >>> struct cannot be reordered,
> >> Yes. (I think this is a Bad Thing, but I can see why they did it.)
> > Given that C is a systems implementation language, how would you
> > define HW rel
> On May 22, 2016, at 5:40 AM, Mouse wrote:
>
First off, the C standard mandates that the order of fields in a
struct cannot be reordered,
>>> Yes. (I think this is a Bad Thing, but I can see why they did it.)
>> Given that C is a systems implementation language, how would you
>> defi
Mouse writes:
> I don't really know FORTH; does it use - for subtraction?
Generally, yes.
>> I'm not even sure
>
>> size_t foo = (size_t)-1;
>
>> is legal,
>
> In C++, I don't know. In C, I'm fairly sure it's legal.
>
>> or even does what I expect it to do (namely---set foo to the largest
>> size_t value possible (pre C99).
>
> I'm not sure it does that. If you want that, I thin
>> Also, PostScript has a lot of language syntax, whereas FORTH has
>> immediate words that act like language syntax. (The difference is
>> that FORTH makes it possible to change those words, thereby changing
>> the apparent syntax.)
> What do you mean by that?
Consider a simple definition
: foo
> I'd wager that most C code is written *assuming* 2's complement and 0
> NULL pointers (and byte addressable, but I didn't ask for that 8-).
Well, yes. I'd go further: I'd wager most C code is written assuming
everything works just the way the developer's system does; most people
I interact with
>>> First off, the C standard mandates that the order of fields in a
>>> struct cannot be reordered,
>> Yes. (I think this is a Bad Thing, but I can see why they did it.)
> Given that C is a systems implementation language, how would you
> define HW related data structures where the order of the f
> On May 21, 2016, at 7:34 PM, ben wrote:
>
> On 5/20/2016 2:58
>
>>
>> [4] Say, a C compiler an 8088. How big is a pointer? How big of an
>> object can you point to? How much code is involved with "p++"?
>
> How come INTEL thought that 64 KB segments ample? I guess they only used
>
It was thus said that the Great ben once stated:
> On 5/20/2016 2:58
>
> >
> >[4] Say, a C compiler an 8088. How big is a pointer? How big of an
> > object can you point to? How much code is involved with "p++"?
>
> How come INTEL thought that 64 KB segments ample? I guess they only used
On 5/20/2016 2:58
[4] Say, a C compiler an 8088. How big is a pointer? How big of an
object can you point to? How much code is involved with "p++"?
How come INTEL thought that 64 KB segments ample? I guess they only used
FLOATING point in the large time shared machines.
Ben.
On 5/21/2016 6:42 AM, Liam Proven wrote:
On 21 May 2016 at 07:14, Sean Conner wrote:
Oh my! I'm reading the manual for the C compiler for the Unisys 2200 [1]
system and it's dated 2013! And yes, it does appear to be a 36-bit non-byte
addressable system.
And you can run the OS free of ch
On Fri, Apr 29, 2016, Mouse wrote:
> Also,
> PostScript has a lot of language syntax, whereas FORTH has immediate
> words that act like language syntax. (The difference is that FORTH
> makes it possible to change those words, thereby changing the apparent
> syntax.)
What do you mean by that?
--
On Sat, May 21, 2016 at 9:59 AM, Guy Sotomayor Jr wrote:
>> On May 21, 2016, at 4:33 AM, Mouse wrote:
>>> First off, the C standard mandates that the order of fields in a
>>> struct cannot be reordered,
>> Yes. (I think this is a Bad Thing, but I can see why they did it.)
> Given that C is a sys
It was thus said that the Great Mouse once stated:
> >>> -spc (Wish the C standard committee had the balls to say "2's
> >>> complement all the way, and a physical bit pattern of all 0s is a
> >>> NULL pointer" ... )
> >> As far as I'm concerned, this is different only in degree from `Wish
>
It was thus said that the Great Mouse once stated:
> >>> -spc (Wish the C standard committee had the balls to say "2's
> >>> complement all the way, and a physical bit pattern of all 0s is a
> >>> NULL pointer" ... )
> >> As far as I'm concerned, this is different only in degree from `Wish
>
On 21 May 2016 at 18:37, Sean Caron wrote:
> On Sat, 21 May 2016, Liam Proven wrote:
>
>> On 21 May 2016 at 07:14, Sean Conner wrote:
>>>
>>>
>>> Oh my! I'm reading the manual for the C compiler for the Unisys 2200
>>> [1]
>>> system and it's dated 2013! And yes, it does appear to be a 36-bit
On Sat, 21 May 2016, Liam Proven wrote:
On 21 May 2016 at 07:14, Sean Conner wrote:
Oh my! I'm reading the manual for the C compiler for the Unisys 2200 [1]
system and it's dated 2013! And yes, it does appear to be a 36-bit non-byte
addressable system.
And you can run the OS free of ch
On 21 May 2016 at 17:58, William Donzelli wrote:
> Yes, I know - but so what? That is nothing new. The IBM 9370 line from
> 20-odd years ago was really an 801 inside, running S/370 in emulation.
I thought it was noteworthy considering that this subthread originated
in discussion of how all conte
> On May 21, 2016, at 4:33 AM, Mouse wrote:
>
>>> Most executables are not performance-critical enough for
>>> dynamic-linker overhead to matter. (For the few that are, or for
>>> the few cases where lots are, yes, static linking can help.)
>> I keep telling myself that whenever I launch Firefo
Yes, I know - but so what? That is nothing new. The IBM 9370 line from
20-odd years ago was really an 801 inside, running S/370 in emulation.
--
Will
On Sat, May 21, 2016 at 11:54 AM, Liam Proven wrote:
> On 21 May 2016 at 17:33, William Donzelli wrote:
>> Unisys is still making new machines as
On 21 May 2016 at 17:33, William Donzelli wrote:
> Unisys is still making new machines as well.
Yes it is, but they are x86 boxes running an emulator.
http://www.theregister.co.uk/2015/05/26/unisys_finally_weans_itself_off_cmos_chippery/
AFAIK only IBM is still making actual hardware mainframe
> Wow!
Unisys is still making new machines as well.
--
Will
On 21 May 2016 at 07:14, Sean Conner wrote:
>
> Oh my! I'm reading the manual for the C compiler for the Unisys 2200 [1]
> system and it's dated 2013! And yes, it does appear to be a 36-bit non-byte
> addressable system.
And you can run the OS free of charge on high-end x86 kit:
http://www.
>> Most executables are not performance-critical enough for
>> dynamic-linker overhead to matter. (For the few that are, or for
>> the few cases where lots are, yes, static linking can help.)
> I keep telling myself that whenever I launch Firefox after a reboot
> ...
Do you have reason to think d
>>> -spc (Wish the C standard committee had the balls to say "2's
>>> complement all the way, and a physical bit pattern of all 0s is a
>>> NULL pointer" ... )
>> As far as I'm concerned, this is different only in degree from `Wish
>> the C standard committee had the balls to say "Everything
Sean Conner writes:
> It was thus said that the Great William Donzelli once stated:
>> There are probably a couple hundred Unisys 2200 systems left in the
>> world
> I suppose this is 1's complement but I see nothing about that in the
> manual
Aka UNISYS 1100/2200, aka ClearPath ix, aka ClearPath
Oh, foo--in 40 years, "C" will be just a quaint recollection in the
minds of the old-timers. Like JOVIAL.
--Chuck
It was thus said that the Great William Donzelli once stated:
> > First off, can you supply a list of architectures that are NOT 2's
> > complement integer math that are still made and in active use today? As far
> > as I can tell, there was only one signed-magnitude architecture ever
> > commer
It was thus said that the Great Mouse once stated:
>
> > 3) It's slower. Two reasons for this:
>
> Even to the extent this is true, in most cases, "so what"?
>
> Most executables are not performance-critical enough for dynamic-linker
> overhead to matter. (For the few that are, or for the
> First off, can you supply a list of architectures that are NOT 2's
> complement integer math that are still made and in active use today? As far
> as I can tell, there was only one signed-magnitude architecture ever
> commercially available (and that in the early 60s) and only a few 1's
> comp
It was thus said that the Great Mouse once stated:
> > -spc (Wish the C standard committee had the balls to say "2's
> > complement all the way, and a physical bit pattern of all 0s is a
> > NULL pointer" ... )
>
> As far as I'm concerned, this is different only in degree from `Wish
> the C
> I'm generally not a fan of shared libraries as:
> 1) Unless you are linking against a library like libc or
> libc++, a lot of memory will be wasted because the *entire*
> library is loaded up, unlike linking to a static library where
> only those functions actually used
> -spc (Wish the C standard committee had the balls to say "2's
> complement all the way, and a physical bit pattern of all 0s is a
> NULL pointer" ... )
As far as I'm concerned, this is different only in degree from `Wish
the C standard committee had the balls to say "Everything is x86".'.
It was thus said that the Great Swift Griggs once stated:
> On Fri, 20 May 2016, Sean Conner wrote:
> > By the late 80s, C was available on many different systems and was not
> > yet standardized.
>
> There were lots of standards, but folks typically gravitated toward K&R or
> ANSI at the time.
On Fri, 20 May 2016, Sean Conner wrote:
> By the late 80s, C was available on many different systems and was not
> yet standardized.
There were lots of standards, but folks typically gravitated toward K&R or
ANSI at the time. Though I was a pre-teen, I was a coder at the time.
Those are pretty
It was thus said that the Great Liam Proven once stated:
> On 29 April 2016 at 19:49, Mouse wrote:
> >
> > It's true that C is easy to use unsafely. However, (a) it arose as an
> > OS implementation language, for which some level of unsafeness is
> > necessary, and (b) to paraphrase a famous rem
On 2016-05-20 3:03 PM, Fred Cisin wrote:
I don't know if that was a specific market ploy based on Moore's Law,
an actually quite smart move, . . .
or just the generally accepted practice of getting an initial version
with the API working any which way, then refactoring to improve
performance/
On 20 May 2016, at 20:03, Fred Cisin wrote:
>> I don't know if that was a specific market ploy based on Moore's Law,
>
> an actually quite smart move, . . .
>
>> or just the generally accepted practice of getting an initial version
>> with the API working any which way, then refactoring to impr
I don't know if that was a specific market ploy based on Moore's Law,
an actually quite smart move, . . .
or just the generally accepted practice of getting an initial version
with the API working any which way, then refactoring to improve
performance/correctness in later versions.
For decad
On 20 May 2016 at 17:24, Liam Proven wrote:
>
> On 18 May 2016 at 21:40, Fred Cisin wrote:
> > But, "Moore's Law" held that it wouldn't be much longer.
> > Just one doubling of the speed of the Lisa's hardware would have been enough
> > to silence the speed complaints.
>
> A general point, really
On 18 May 2016 at 21:40, Fred Cisin wrote:
> But, "Moore's Law" held that it wouldn't be much longer.
> Just one doubling of the speed of the Lisa's hardware would have been enough
> to silence the speed complaints.
A general point, really.
One of Microsoft's strokes of brilliance was selective
On 29 April 2016 at 19:49, Mouse wrote:
>>> True, but again, *you shouldn't have to*. It means programmer
>>> effort, brain power, is being wasted on thinking about being safe
>>> instead of spent on writing better programs.
>
> True, but...
>
>> One side effect of this is that it makes a lot of C
Apple Lisa operating system . . .
implemented in Pascal
. . . . which was a pretty big mainstream success for proving
Pascal as suitable for developing systems software.
"Apple hired brilliant people for the project. BUT, they had so little
real-world experience that they didn't even realize wh
On May 18, 2016, at 8:33 AM, John Willis wrote:
> Let's not forget that the bulk of the Apple Lisa operating system and
> at least large parts of the original Macintosh system software were also
> implemented in Pascal (though IIRC hand-translated into 68k assembly
> language), which was a pretty
On Wed, 18 May 2016, Toby Thain wrote:
> [...] Some languages used before 1974 were even better suited than C to
> this purpose. Do people think computers didn't exist before 1974?!
Only the cool kids could touch them until the "personal" computers started
coming along. I'm not really aware of w
It was thus said that the Great Fred Cisin once stated:
> On Wed, 18 May 2016, John Willis wrote:
> >Let's not forget that the bulk of the Apple Lisa operating system and
> >at least large parts of the original Macintosh system software were also
> >implemented in Pascal (though IIRC hand-translate
On 2016-05-18 3:17 PM, Paul Koning wrote:
On May 18, 2016, at 2:44 PM, Fred Cisin wrote:
On Wed, 18 May 2016, John Willis wrote:
Let's not forget that the bulk of the Apple Lisa operating system and
at least large parts of the original Macintosh system software were also
implemented in Pasca
On 2016-05-18 3:40 PM, Fred Cisin wrote:
At the time, it was sometimes interpreted differently: "Apple hired
brilliant people for the project. BUT, they had so little real-world
experience that they didn't even realize what a mistake it would be
to write an OS in a high level language.
On Wed,
At the time, it was sometimes interpreted differently: "Apple hired
brilliant people for the project. BUT, they had so little real-world
experience that they didn't even realize what a mistake it would be to
write an OS in a high level language.
On Wed, 18 May 2016, Paul Koning wrote:
What a
> On May 18, 2016, at 2:44 PM, Fred Cisin wrote:
>
> On Wed, 18 May 2016, John Willis wrote:
>> Let's not forget that the bulk of the Apple Lisa operating system and
>> at least large parts of the original Macintosh system software were also
>> implemented in Pascal (though IIRC hand-translated
On Wed, 18 May 2016, Fred Cisin wrote:
On Wed, 18 May 2016, Sean Caron wrote:
Pascal was probably the predominant applications development language on
Mac OS through the mid 1990s or so, no? Certainly all the Toolbox bindings
were originally written with the idea that people would be developin
On Wed, 18 May 2016, Sean Caron wrote:
Pascal was probably the predominant applications development language on Mac
OS through the mid 1990s or so, no? Certainly all the Toolbox bindings were
originally written with the idea that people would be developing in Pascal.
Windoze also used Pascal s
On Wed, 18 May 2016, John Willis wrote:
Let's not forget that the bulk of the Apple Lisa operating system and
at least large parts of the original Macintosh system software were also
implemented in Pascal (though IIRC hand-translated into 68k assembly
language), which was a pretty big mainstream
On Wed, 18 May 2016, John Willis wrote:
The problem is that type #2 here covers most people, and sadly, the
ivory towers of the industry & academia do not accept that certain
languages or language features are actually widely-liked or attractive
to people because they do not fit with the preva
>
>
> The problem is that type #2 here covers most people, and sadly, the
> ivory towers of the industry & academia do not accept that certain
> languages or language features are actually widely-liked or attractive
> to people because they do not fit with the prevailing wisdom. So,
> although, for
On 17 May 2016 at 20:21, Sean Conner wrote:
> It was thus said that the Great Liam Proven once stated:
>> This has been waiting for a reply for too long...
>
> As has this ...
:-)
>> On 4 May 2016 at 20:59, Sean Conner wrote:
>> >
>> > Part of that was the MMU-less 68000. It certainly made
On May 17, 2016, at 11:21 AM, Sean Conner wrote:
>
> While the Amiga may have "cheated" by passing a reference to the message
> instead of copying it, conceptually, it was passing a message (for all the
> user knows, the message *could* be copied before being sent). I still
> consider AmigaOS a
On May 11, 2016, at 5:41 PM, ben wrote:
>
> On 5/11/2016 5:54 PM, Toby Thain wrote:
>> On 2016-05-11 7:43 PM, Liam Proven wrote:
>>> ...
>>> If we'd had 4 decades of effort aimed at fast Lisp Machines, I think
>>> we'd have them.
>>
>> Compiled Lisp, even on generic hardware, is fast. Fast enoug
It was thus said that the Great Liam Proven once stated:
> This has been waiting for a reply for too long...
As has this ...
> On 4 May 2016 at 20:59, Sean Conner wrote:
> >
> > Part of that was the MMU-less 68000. It certainly made message passing
> > cheap (since you could just send a poi
From: ben
Sent: Wednesday, May 11, 2016 5:42 PM
> On 5/11/2016 5:54 PM, Toby Thain wrote:
>> On 2016-05-11 7:43 PM, Liam Proven wrote:
>>> If we'd had 4 decades of effort aimed at fast Lisp Machines, I think
>>> we'd have them.
>> Compiled Lisp, even on generic hardware, is fast. Fast enough, i
>> Compiled Lisp, even on generic hardware, is fast. [...]
> But List still sequential processing as far as I can see? How do you
> speed that up?
Just as sequential as C or PL/I or whatever else.
As for speeding it up? As a compiler geek I'm strictly a dilettante,
so I don't really know, but
On 5/11/2016 5:54 PM, Toby Thain wrote:
On 2016-05-11 7:43 PM, Liam Proven wrote:
...
If we'd had 4 decades of effort aimed at fast Lisp Machines, I think
we'd have them.
Compiled Lisp, even on generic hardware, is fast. Fast enough, in fact,
that it obviated Symbolics. (More in Richard P. Gab
On 2016-05-11 7:43 PM, Liam Proven wrote:
...
If we'd had 4 decades of effort aimed at fast Lisp Machines, I think
we'd have them.
Compiled Lisp, even on generic hardware, is fast. Fast enough, in fact,
that it obviated Symbolics. (More in Richard P. Gabriel's history of
Lucid.) See also: The
This has been waiting for a reply for too long...
On 4 May 2016 at 20:59, Sean Conner wrote:
> It was thus said that the Great Liam Proven once stated:
>> On 29 April 2016 at 21:06, Sean Conner wrote:
>> > It was thus said that the Great Liam Proven once stated:
>>
>> > I read that and it does
>Mouse wrote:
Note that PDP-11 autoincrement and autodecrement exist only when
operating on pointers that are being indirected through, and even then
only when the pointers are in registers. C ++ and -- work fine on
things other than pointers, and on pointers when not indirecting
through them.
>Dave Wade wrote:
Fortran has an EQUIVALENCE statement, COBOL has redefines. Both allows the
subversion of types at the drop of a hat.
I can think of two examples which were not so much subversion of types
as they were a lack of language flexibility:
(a) Very early in my FORTRAN experience,
From: Sean Conner
Sent: Wednesday, May 04, 2016 12:00 PM
> It was thus said that the Great Liam Proven once stated:
>> The way LispMs worked, AIUI, is that the machine language wasn't Lisp,
>> it was something far simpler, but designed to map onto Lisp concepts.
> The Lisp machines had tagged me
It was thus said that the Great Liam Proven once stated:
> On 29 April 2016 at 21:06, Sean Conner wrote:
> > It was thus said that the Great Liam Proven once stated:
>
> > I read that and it doesn't really seem that CAOS would have been much
> > better than what actually came out. Okay, the po
On 29 April 2016 at 22:23, Eric Smith wrote:
> More than 95% of my work is in C,
> because that's what my clients demand, so people are usually surprised
> to hear my opinion that C is a terrible choice for almost anything.
I am in an analogous boat. Most of my career has been based on
Windows,
On 30 April 2016 at 06:36, Tapley, Mark wrote:
> On Apr 28, 2016, at 8:38 AM, Liam Proven wrote:
>
>> I loved BeOS but never saw the Be Book. :-(
>
> Sorry if this is a duplicate, I’m behind on the list by a little. I think the
> Be Book is effectively on-line at
>
> https://www.haiku-os.org/leg
On 29 April 2016 at 21:06, Sean Conner wrote:
> It was thus said that the Great Liam Proven once stated:
>>
>> Do you really think it's growing? I'd like very much to believe that.
>> I see little sign of it. I do hope you're right.
>
> I read Hacker News and some of the more programmer related
On 29 April 2016 at 16:51, Brian L. Stuart wrote:
> On Thu, 4/28/16, Liam Proven wrote:
The efforts to fix and improve Unix -- Plan 9, Inferno -- forgotten.
>>
>> It is, true, but it's a sideline now. And the steps made by Inferno
>> seem to have had even less impact. I'd like to see the 2 m
On 2016-04-30 5:20 PM, Chuck Guzis wrote:
On 04/30/2016 02:07 PM, Mouse wrote:
Reading this really gives me the impression that it's time to fork
C. There seems to me to be a need for two different languages, which
I might slightly inaccurately call the one C used to be and the one
it has becom
On 04/30/2016 04:31 PM, Sean Conner wrote:
> I believe that's what the C99 keyword "restrict" is meant to address.
Closing the barn door after the horses have run off. It's not in C++
and *must* be included by the programmer. I suspect if you take 100 C99
programs, 99 of them will not include "
> On Apr 30, 2016, at 6:39 AM, Diane Bruce wrote:
>
> On Fri, Apr 29, 2016 at 03:55:35PM -0700, Chuck Guzis wrote:
>> Those who claim that there's not much difference between C and assembly
>> language have never run into a true CISC machine--or perhaps they rely
>> only on libraries someone els
1 - 100 of 297 matches
Mail list logo
